Комментарии 22
По-моему, ничего нового, ты просто взял технологию использования атрибутов и методы-расширения и смешал всё вместе.
-2
А бывает как-то по-другому? Я ведь, прежде всего, расскал о, на мой взгляд, интересном варианте решения определенной задачи.
Для Вас ничего нового, другим, возможно, будет интересно. Ведь даже знание определенных технологий не обязательно означает отсутствие интереса в практических примерах их применения. Взять, для примера, шахматы. Достаточно ли для победы над сильным соперником знать, что конь ходит буквой «Г», а слон — по-диагонали? :)
Для Вас ничего нового, другим, возможно, будет интересно. Ведь даже знание определенных технологий не обязательно означает отсутствие интереса в практических примерах их применения. Взять, для примера, шахматы. Достаточно ли для победы над сильным соперником знать, что конь ходит буквой «Г», а слон — по-диагонали? :)
+1
согласен, нового вообще не увидел, все те же буквы с алфавита )))
а вообще идея мне понравилась.а то часто бывает что для enum надо еще одно поле и приходилось извращаться.
а вообще идея мне понравилась.а то часто бывает что для enum надо еще одно поле и приходилось извращаться.
0
дело в том, что есть мнение, что смешивать данные и код — это плохая практика. завтра вам понадобится добавить одно слово к описанию и вы будете лезть в код, компилировать обновлять сайт, что может занять кучу бесполезно потраченного времени. Лучше получать данные из внешних источников данных, это можно делать и с помощью артибутов, если они вам понравились. :-)
+5
+ если сериализовывать/десериализовывать объекты (например, отдать через веб-сервис), то атрибуты благополучно теряются
-1
Владимир, да, ведь я же слово «сайт» в посте ни разу не упомянул. Текст не к ASP.NET, а к языку в целом. Соответственно, во внешних источниках хранить данные и позволять пользователям, к примеру, WinForms-приложения менять значения — не всегда подходящее решение.
Кроме того, ведь не любая информация гипотетически может изменяться. Есть ведь такое понятие — константы. Мы же когда создаем константы не волнуемся на счет того, что надо бы вынести, к примеру, значение константы SECONDS_IN_HOUR во внешний источник. Также и с перечислениями — множество значений параметров у элементов перечислений, которые нам хотелось бы задать, просто по человеческой логике не потребуется изменить.
Не убедил? :)
Кроме того, ведь не любая информация гипотетически может изменяться. Есть ведь такое понятие — константы. Мы же когда создаем константы не волнуемся на счет того, что надо бы вынести, к примеру, значение константы SECONDS_IN_HOUR во внешний источник. Также и с перечислениями — множество значений параметров у элементов перечислений, которые нам хотелось бы задать, просто по человеческой логике не потребуется изменить.
Не убедил? :)
+1
тут скорее пример не удачный. иногда так не хватает кроме ID и Name для enum еще какого нибудь свойства. То что предложено, идеально подходит для таких случаев на мой взгляд.
0
Есть пара замечаний
Первое — рефлексия это всегда определенный урон скорости
Второе — типы для дженериков рекомендуется начинать с 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 — если вам нужно добавить данных — добавляйте их в источники а не в виде вкомпилированных констант. Оба примера гораздо более изящно решаются через данные и локализацию чем вот такими подходами.
Но в общем — продолжайте писать и изучать, все мы начинали с изобретения своих велосипедов. И плох тот программист который ни разу не пытался переизобрести хотя бы самокат =)
0
Да, согласен, о производительности стоило упомянуть.
Относительно типов у дженериков я в курсе, просто руководствовался рекомендациями по оформлению кода из Хаброблога .NET. Там об этом, вроде как, ни слова, а префикс T вызывает у меня ассоциации с VCL и Delphi (TForm, TButton, TCheckbox...), т.к. в свое время переполз с него на C#. А вообще, наверное, это смотрится скорее непривычно, чем странно. :)
Второй абзац я уже прокомментировал здесь.
Спасибо. Будем стараться! :)
Относительно типов у дженериков я в курсе, просто руководствовался рекомендациями по оформлению кода из Хаброблога .NET. Там об этом, вроде как, ни слова, а префикс T вызывает у меня ассоциации с VCL и Delphi (TForm, TButton, TCheckbox...), т.к. в свое время переполз с него на C#. А вообще, наверное, это смотрится скорее непривычно, чем странно. :)
Второй абзац я уже прокомментировал здесь.
Спасибо. Будем стараться! :)
+1
Я откровенно против такого подхода. Единственно легитивный use case при аттрибутировании enum-значений – это чтобы они не смотрелись убого в property grid и подобных контролах. И то, с локализацией этот подход не особо дружит.
Я вообще не понимаю зачем создавать
Строго не сужу. Даже капнул в карму чтобы вы могли писать в .Net. Удачи!
Я вообще не понимаю зачем создавать
enum Womans
(кстате plural от woman = women) если можно создать class Woman
и потом сделать Woman [] women
. Обход по enum
у сам по себе дорогой, а если еще аттрибуты через reflection вытягивать, так совсем неэффективно.Строго не сужу. Даже капнул в карму чтобы вы могли писать в .Net. Удачи!
+1
Ну зачем же так строго судить пост?
Я точно видела как много разных программистов используют:
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)
{
//бла-бла-бла
}
по сути, это то, что показал автор, но ввиду неопытности привёл холиварный пример который затрагивает локализацию с помесь данных и их представление.
Я.
+1
Ну, это же совсем другое дело.
Во-первых, такую разметку требуют обычно hand-made O/R-проекторы, и к локализации она не имеет никакого отношения. А во-вторых, тут ясно известно, что есть обращение к БД, а это само по себе на порядок медленнее рефлексии и на этом фоне просадка из-за рефлексии нивелируется.
Во-первых, такую разметку требуют обычно hand-made O/R-проекторы, и к локализации она не имеет никакого отношения. А во-вторых, тут ясно известно, что есть обращение к БД, а это само по себе на порядок медленнее рефлексии и на этом фоне просадка из-за рефлексии нивелируется.
0
Ого!
Поразило. Срочно фрэнди, если знаешь как на английском сказать: нивелируется, просадка, порядок медленнее.
Ужас. Но, экспресия понятна. Цём.
Поразило. Срочно фрэнди, если знаешь как на английском сказать: нивелируется, просадка, порядок медленнее.
Ужас. Но, экспресия понятна. Цём.
0
а мне, например, статья понравилась, хорошо написано
но не обратить внимание на некоторые вопросы я не мог
но не обратить внимание на некоторые вопросы я не мог
+2
На самом деле, дело в неправильном использовании перечислений.
В вашем случае нужны полноценные объекты, а не перечисления с корявыми свойствами.
В вашем случае нужны полноценные объекты, а не перечисления с корявыми свойствами.
-1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Изменить настройки темы
Имитация свойств для элементов перечислений (Enumerations) в .NET Framework 3.5