Комментарии 22
По-моему, ничего нового, ты просто взял технологию использования атрибутов и методы-расширения и смешал всё вместе.
А бывает как-то по-другому? Я ведь, прежде всего, расскал о, на мой взгляд, интересном варианте решения определенной задачи.
Для Вас ничего нового, другим, возможно, будет интересно. Ведь даже знание определенных технологий не обязательно означает отсутствие интереса в практических примерах их применения. Взять, для примера, шахматы. Достаточно ли для победы над сильным соперником знать, что конь ходит буквой «Г», а слон — по-диагонали? :)
Для Вас ничего нового, другим, возможно, будет интересно. Ведь даже знание определенных технологий не обязательно означает отсутствие интереса в практических примерах их применения. Взять, для примера, шахматы. Достаточно ли для победы над сильным соперником знать, что конь ходит буквой «Г», а слон — по-диагонали? :)
согласен, нового вообще не увидел, все те же буквы с алфавита )))
а вообще идея мне понравилась.а то часто бывает что для enum надо еще одно поле и приходилось извращаться.
а вообще идея мне понравилась.а то часто бывает что для enum надо еще одно поле и приходилось извращаться.
дело в том, что есть мнение, что смешивать данные и код — это плохая практика. завтра вам понадобится добавить одно слово к описанию и вы будете лезть в код, компилировать обновлять сайт, что может занять кучу бесполезно потраченного времени. Лучше получать данные из внешних источников данных, это можно делать и с помощью артибутов, если они вам понравились. :-)
+ если сериализовывать/десериализовывать объекты (например, отдать через веб-сервис), то атрибуты благополучно теряются
Владимир, да, ведь я же слово «сайт» в посте ни разу не упомянул. Текст не к ASP.NET, а к языку в целом. Соответственно, во внешних источниках хранить данные и позволять пользователям, к примеру, WinForms-приложения менять значения — не всегда подходящее решение.
Кроме того, ведь не любая информация гипотетически может изменяться. Есть ведь такое понятие — константы. Мы же когда создаем константы не волнуемся на счет того, что надо бы вынести, к примеру, значение константы SECONDS_IN_HOUR во внешний источник. Также и с перечислениями — множество значений параметров у элементов перечислений, которые нам хотелось бы задать, просто по человеческой логике не потребуется изменить.
Не убедил? :)
Кроме того, ведь не любая информация гипотетически может изменяться. Есть ведь такое понятие — константы. Мы же когда создаем константы не волнуемся на счет того, что надо бы вынести, к примеру, значение константы SECONDS_IN_HOUR во внешний источник. Также и с перечислениями — множество значений параметров у элементов перечислений, которые нам хотелось бы задать, просто по человеческой логике не потребуется изменить.
Не убедил? :)
тут скорее пример не удачный. иногда так не хватает кроме ID и Name для enum еще какого нибудь свойства. То что предложено, идеально подходит для таких случаев на мой взгляд.
Когда то писал об этом трюке, для меня это достаточно удобно.
Есть пара замечаний
Первое — рефлексия это всегда определенный урон скорости
Второе — типы для дженериков рекомендуется начинать с T, даже в мсдне об этом пишут. Очень странно на мой взгляд смотрится
VAL GetAttributeValue<ENUM, VAL>(this ENUM enumItem, Type attributeType, VAL defaultValue)
В остальном же согласен с XaosCPS — если вам нужно добавить данных — добавляйте их в источники а не в виде вкомпилированных констант. Оба примера гораздо более изящно решаются через данные и локализацию чем вот такими подходами.
Но в общем — продолжайте писать и изучать, все мы начинали с изобретения своих велосипедов. И плох тот программист который ни разу не пытался переизобрести хотя бы самокат =)
Первое — рефлексия это всегда определенный урон скорости
Второе — типы для дженериков рекомендуется начинать с T, даже в мсдне об этом пишут. Очень странно на мой взгляд смотрится
VAL GetAttributeValue<ENUM, VAL>(this ENUM enumItem, Type attributeType, VAL defaultValue)
В остальном же согласен с XaosCPS — если вам нужно добавить данных — добавляйте их в источники а не в виде вкомпилированных констант. Оба примера гораздо более изящно решаются через данные и локализацию чем вот такими подходами.
Но в общем — продолжайте писать и изучать, все мы начинали с изобретения своих велосипедов. И плох тот программист который ни разу не пытался переизобрести хотя бы самокат =)
Да, согласен, о производительности стоило упомянуть.
Относительно типов у дженериков я в курсе, просто руководствовался рекомендациями по оформлению кода из Хаброблога .NET. Там об этом, вроде как, ни слова, а префикс T вызывает у меня ассоциации с VCL и Delphi (TForm, TButton, TCheckbox...), т.к. в свое время переполз с него на C#. А вообще, наверное, это смотрится скорее непривычно, чем странно. :)
Второй абзац я уже прокомментировал здесь.
Спасибо. Будем стараться! :)
Относительно типов у дженериков я в курсе, просто руководствовался рекомендациями по оформлению кода из Хаброблога .NET. Там об этом, вроде как, ни слова, а префикс T вызывает у меня ассоциации с VCL и Delphi (TForm, TButton, TCheckbox...), т.к. в свое время переполз с него на C#. А вообще, наверное, это смотрится скорее непривычно, чем странно. :)
Второй абзац я уже прокомментировал здесь.
Спасибо. Будем стараться! :)
Я откровенно против такого подхода. Единственно легитивный use case при аттрибутировании enum-значений – это чтобы они не смотрелись убого в property grid и подобных контролах. И то, с локализацией этот подход не особо дружит.
Я вообще не понимаю зачем создавать
Строго не сужу. Даже капнул в карму чтобы вы могли писать в .Net. Удачи!
Я вообще не понимаю зачем создавать
enum Womans (кстате plural от woman = women) если можно создать class Woman и потом сделать Woman [] women. Обход по enumу сам по себе дорогой, а если еще аттрибуты через reflection вытягивать, так совсем неэффективно.Строго не сужу. Даже капнул в карму чтобы вы могли писать в .Net. Удачи!
Ну зачем же так строго судить пост?
Я точно видела как много разных программистов используют:
public class Model
{
[SqlInputParameter("@Name")]
public string Name { get; set; }
[SqlInputParameter("@Value")]
public int Value { get; set;}
}
и адаптер к моделям:
SqlParameterCollection GetParameters(object model)
{
//бла-бла-бла
}
по сути, это то, что показал автор, но ввиду неопытности привёл холиварный пример который затрагивает локализацию с помесь данных и их представление.
Я.
Я точно видела как много разных программистов используют:
public class Model
{
[SqlInputParameter("@Name")]
public string Name { get; set; }
[SqlInputParameter("@Value")]
public int Value { get; set;}
}
и адаптер к моделям:
SqlParameterCollection GetParameters(object model)
{
//бла-бла-бла
}
по сути, это то, что показал автор, но ввиду неопытности привёл холиварный пример который затрагивает локализацию с помесь данных и их представление.
Я.
Ну, это же совсем другое дело.
Во-первых, такую разметку требуют обычно hand-made O/R-проекторы, и к локализации она не имеет никакого отношения. А во-вторых, тут ясно известно, что есть обращение к БД, а это само по себе на порядок медленнее рефлексии и на этом фоне просадка из-за рефлексии нивелируется.
Во-первых, такую разметку требуют обычно hand-made O/R-проекторы, и к локализации она не имеет никакого отношения. А во-вторых, тут ясно известно, что есть обращение к БД, а это само по себе на порядок медленнее рефлексии и на этом фоне просадка из-за рефлексии нивелируется.
а мне, например, статья понравилась, хорошо написано
но не обратить внимание на некоторые вопросы я не мог
но не обратить внимание на некоторые вопросы я не мог
На самом деле, дело в неправильном использовании перечислений.
В вашем случае нужны полноценные объекты, а не перечисления с корявыми свойствами.
В вашем случае нужны полноценные объекты, а не перечисления с корявыми свойствами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Имитация свойств для элементов перечислений (Enumerations) в .NET Framework 3.5