Pull to refresh

Comments 22

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

Для Вас ничего нового, другим, возможно, будет интересно. Ведь даже знание определенных технологий не обязательно означает отсутствие интереса в практических примерах их применения. Взять, для примера, шахматы. Достаточно ли для победы над сильным соперником знать, что конь ходит буквой «Г», а слон — по-диагонали? :)
согласен, нового вообще не увидел, все те же буквы с алфавита )))

а вообще идея мне понравилась.а то часто бывает что для enum надо еще одно поле и приходилось извращаться.
дело в том, что есть мнение, что смешивать данные и код — это плохая практика. завтра вам понадобится добавить одно слово к описанию и вы будете лезть в код, компилировать обновлять сайт, что может занять кучу бесполезно потраченного времени. Лучше получать данные из внешних источников данных, это можно делать и с помощью артибутов, если они вам понравились. :-)
+ если сериализовывать/десериализовывать объекты (например, отдать через веб-сервис), то атрибуты благополучно теряются
Что любопытно, поведение сериализацией регулируется, в том числе, и атрибутами. :)
Не всегда.
WCF предоставляет возможность переиспользовать объекты.
Владимир, да, ведь я же слово «сайт» в посте ни разу не упомянул. Текст не к ASP.NET, а к языку в целом. Соответственно, во внешних источниках хранить данные и позволять пользователям, к примеру, WinForms-приложения менять значения — не всегда подходящее решение.

Кроме того, ведь не любая информация гипотетически может изменяться. Есть ведь такое понятие — константы. Мы же когда создаем константы не волнуемся на счет того, что надо бы вынести, к примеру, значение константы SECONDS_IN_HOUR во внешний источник. Также и с перечислениями — множество значений параметров у элементов перечислений, которые нам хотелось бы задать, просто по человеческой логике не потребуется изменить.

Не убедил? :)
с приложениями все еще хуже, если установок несколько тысяч, то ради одной строчки текста их все обновлять — это ужос. потенциальный. :-)

я вас понял, соглашусь, что все в меру полезно и вредно при передозировке. использовать можно, когда трезво оценил возможные издержки.
тут скорее пример не удачный. иногда так не хватает кроме ID и Name для enum еще какого нибудь свойства. То что предложено, идеально подходит для таких случаев на мой взгляд.
Есть пара замечаний
Первое — рефлексия это всегда определенный урон скорости
Второе — типы для дженериков рекомендуется начинать с T, даже в мсдне об этом пишут. Очень странно на мой взгляд смотрится
VAL GetAttributeValue<ENUM, VAL>(this ENUM enumItem, Type attributeType, VAL defaultValue)

В остальном же согласен с XaosCPS — если вам нужно добавить данных — добавляйте их в источники а не в виде вкомпилированных констант. Оба примера гораздо более изящно решаются через данные и локализацию чем вот такими подходами.

Но в общем — продолжайте писать и изучать, все мы начинали с изобретения своих велосипедов. И плох тот программист который ни разу не пытался переизобрести хотя бы самокат =)
Да, согласен, о производительности стоило упомянуть.

Относительно типов у дженериков я в курсе, просто руководствовался рекомендациями по оформлению кода из Хаброблога .NET. Там об этом, вроде как, ни слова, а префикс T вызывает у меня ассоциации с VCL и Delphi (TForm, TButton, TCheckbox...), т.к. в свое время переполз с него на C#. А вообще, наверное, это смотрится скорее непривычно, чем странно. :)

Второй абзац я уже прокомментировал здесь.

Спасибо. Будем стараться! :)
Я откровенно против такого подхода. Единственно легитивный use case при аттрибутировании enum-значений – это чтобы они не смотрелись убого в property grid и подобных контролах. И то, с локализацией этот подход не особо дружит.
Я вообще не понимаю зачем создавать 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)
{
//бла-бла-бла
}

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

Я.
Ну, это же совсем другое дело.
Во-первых, такую разметку требуют обычно hand-made O/R-проекторы, и к локализации она не имеет никакого отношения. А во-вторых, тут ясно известно, что есть обращение к БД, а это само по себе на порядок медленнее рефлексии и на этом фоне просадка из-за рефлексии нивелируется.
Ого!
Поразило. Срочно фрэнди, если знаешь как на английском сказать: нивелируется, просадка, порядок медленнее.

Ужас. Но, экспресия понятна. Цём.
Сдается мне, 6 утра — не самое лучшее время для выражения мыслей ) Однако, по порядку:
— neutralizing, eliminating;
— sagging, kickdown, depression, gap, slip, (drawdown);
— order of magnitude;

но таки фейл, да, особенно с просадкой :/
а мне, например, статья понравилась, хорошо написано
но не обратить внимание на некоторые вопросы я не мог
Ну, да… по-сути хорошо. Вот только уж очень стнёмный пример с Enum & Attributes. :)
Просто как IE vs FireFox :) Пример бы более абстрактный и всё было бы ок. Радует одно, — в этом блоге фанатиков нет. Нет, ребята, честно приятно.
На самом деле, дело в неправильном использовании перечислений.

В вашем случае нужны полноценные объекты, а не перечисления с корявыми свойствами.
Only those users with full accounts are able to leave comments. Log in, please.