Считаете ли вы, что атрибуты C # (или аналогичные механизмы) - это хорошая идея, или вы не рекомендуете их использовать? - PullRequest
3 голосов
/ 17 апреля 2009

За последние 4 или 5 лет я основал множество проектов и сред, в которых используются атрибуты C #.

Но в последнее время я вижу, что многие люди открыто не одобряют их использование или меняют свои структуры, чтобы уменьшить необходимость или использование их.

Я нашел их находкой, но теперь начинаю задумываться, чего мне не хватает.

уточнить: Соглашение об использовании над конфигурацией становится основным принципом, которому необходимо следовать, особенно в области ORM. В этой области вы можете сопоставить поля с файлом конфигурации (XML), использовать атрибут или иметь общее соглашение об именах, которое сопоставляется непосредственно с полями в таблицах вашей базы данных. У меня нет ссылок на цитаты, но я прочитал некоторую обратную реакцию против добавления другого атрибута к миксу.

Но я чувствую из трех вариантов, которые я только что перечислил, Атрибуты все еще имеют смысл. Файл конфигурации сложнее поддерживать, и общее соглашение об именах связывает вас с реализацией поля базы данных. Атрибуты размещаются именно там, где они необходимы, и реализация может меняться, не отключаясь от того, где она используется.

Ответы [ 7 ]

7 голосов
/ 17 апреля 2009

Это сложный вопрос, на который можно дать общий ответ. Атрибуты - это еще одна языковая функция, которая невероятно мощна при правильном использовании, но потенциально может стать причиной злоупотреблений. Я никогда не видел убедительной причины полностью отказаться от использования атрибутов, и на самом деле нет причин думать, что они плохая идея.

На самом деле, все наоборот. Атрибуты позволяют добавлять специфичную для каркаса информацию в метаданные. Информация, которая просто не может быть легко выражена через иерархию типов. Это значительно увеличивает возможности структур, которые используют атрибуты.

Я, конечно, видел одну или две реализации, где люди немного злоупотребляли ими, но ничего впечатляющего. Можете быть более конкретными? Есть ли конкретные атрибуты / рамки, о которых вы говорите?

5 голосов
/ 17 апреля 2009

Это довольно широкий вопрос, типа «я должен положить сыр в свою запеканку»; Ответ на оба вопроса: «это зависит от того, что вы делаете».

Если вы интенсивно используете надстройки и используете их почти как декларативную парадигму программирования, то вы, вероятно, столкнетесь с проблемами на этом пути. Происходит ли это из-за замедления где-то в рефлексии или просто из-за общей ремонтопригодности?

Это похоже на все остальное ... используйте их, когда они уместны, и сделайте ваш код более эффективным или читабельным. Не используйте их ради их использования и не оставляйте их ради того, чтобы оставить их.

3 голосов
/ 17 апреля 2009

Атрибуты на самом деле имеют две цели: как видимые пользователю вещи и как вещи, испускаемые компилятором.

Я полагаю, вы говорите о видимых пользователем атрибутах.

В целом, я бы сказал, что видимые пользователю атрибуты не идеальны.

Большую часть времени они используются для встраивания какой-либо формы пользовательского языка поверх C #. Атрибуты DLINQ являются хорошим примером этого. Лучшим подходом, с точки зрения потребителя, было бы добавить первоклассную поддержку к языку хоста. Это будет в конечном итоге чувствовать себя гораздо более естественным. (имея языковую поддержку для определения таблиц и внешних ключей было бы намного легче работать со всеми безумными атрибутами linq-to-sql).

В действительности, однако, расширение языка программирования слишком затратно для большинства разработчиков. Преимущества просто не взвешивают затраты.

Возможно, когда-нибудь в C # появятся функции метапрограммирования, которые упростят такую ​​задачу.

Однако на данный момент такой возможности не существует.

Это оставляет вам 3 варианта:

  1. Использовать атрибуты
  2. Использование динамического языка и генерация кода во время выполнения
  3. Только не используйте генеративное программирование

Обычно № 1 оказывается самым простым выбором, даже если он не идеален.

2 голосов
/ 17 апреля 2009

Я считаю их чрезвычайно полезными, когда речь идет об определении метаданных о моем коде. Я использую их для создания пользовательских отчетов, для архитектуры подключаемых модулей и для связи со сторонним кодом.

Полагаю, вы можете делать все по соглашению, но они мне нравятся.

1 голос
/ 17 апреля 2009

Я вижу интенсивное использование атрибутов в ASP.NET MVC. На самом деле, переход на MVC заставил меня значительно увеличить использование атрибутов. Я не уверен, откуда исходит ваша реакция на негативную реакцию на атрибуты, но я определенно не вижу ее в MS, по крайней мере, в отношении MVC.

Мне особенно нравится способ, которым атрибуты могут использоваться для обеспечения сквозного поведения (аспектов) для тех контроллеров / действий, которые так украшены. Видя, как MVC построен для обработки вызова атрибутов до и после вызова действия, я должен поверить, что это предпочтительный способ заставить аспекты работать в MVC.

0 голосов
/ 17 апреля 2009

Я лично считаю, что атрибуты, как и большинство языковых функций, имеют свое место, но ими можно злоупотреблять или злоупотреблять.

В правильных рамках они бесценны. Они определенно упрощают такие вещи, как DI-фреймворки (отличный пример MEF ), и очень, очень полезны для таких вещей, как тестирование фреймворков.

Я думаю, что сойти с ума, добавив пользовательские атрибуты, может быть излишним. Я лично люблю использовать атрибуты, но стараюсь сводить их к минимуму, и использую их только там, где они имеют смысл.

0 голосов
/ 17 апреля 2009

Что ж, если ASP.NET MVC что-то может пройти, я бы сказал, не беспокойтесь об этом. В этой среде с помощью рефлексии и атрибутов сделано так много, что я не вижу в этом никаких проблем. MVC - это довольно новый фреймворк, и он используется повсеместно. От проверки ввода, обработки ошибок до очень удивительного атрибута ActionFilter - их много. Так что нет, я лично не вижу в них ничего плохого.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...