Каков наилучший способ разработки приложения с сущностями, которые могут быть расширены с помощью дополнительных атрибутов? - PullRequest
Новая
       6

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

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

Поиск советов, ссылок, шаблонов проектирования и т. Д. О наилучшем способе разработки приложения, в котором объекты и связанные с ними экраны могут быть расширены с помощью дополнительных атрибутов / связанных поисков через метаданные / без перекомпиляции, в идеале конечными пользователями. Я думаю, что очень похоже на то, как Dynamics CRM 4.0 работает с таблицами расширений / динамическими свойствами. Это приложение будет построено с использованием C # .NET 3.5

Спасибо!

Ответы [ 2 ]

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

Вы можете сделать это, написав свою собственную реализацию PropertyDescriptor и либо внедрив ICustomTypeDescriptor (добавляет свойства в экземпляр ), либо используя TypeDescriptionProvider (можно добавить свойства на весь тип ).

Это распространенный способ реализации расширяемых / динамических реализаций пакетов свойств, и это то, что DataTable использует под капотом для демонстрации виртуальных свойств (в DataRowView и т. Д.).

Тем не менее, это много работы. Я делал это несколько раз, и это не весело. Интересно, стоит ли вам просто использовать консервированное решение? Хотя я обычно избегаю DataTable, это может быть один из случаев, когда это действительно полезно ... просто добавьте столбцы, и работа сделана.

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

Я работал над двумя проектами: один - портал системы управления контентом Telco, другой - система управления идентификацией.

Оба являются настройками продуктов, и оба поддерживают то, что вы описали как расширения сущностей. И оба хранят данные как ... строки XML! (Один из них в базе данных, другой в SVN).

Для поиска один из них использует Lucene, а другой имеет таблицу пары имя / значение для поиска с оптимизацией для некоторых более часто используемых «полей», определенных пользователем для хранения в той же строке, что и XML строка ..

Схема объекта управляется XML-файлами конфигурации.

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

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

  1. Учитывая способность расширять сущность по своему желанию, кто будет тем, кто расширяет их? Программист? Бизнес-пользователь?
  2. Учитывая, что вы сузили их до того, кто будет выполнять «настройку», как вы можете сделать его более приятным? Вывести дизайн из использования.

Кроме того, учтите это: Вам действительно нужна СУБД для этого, или для хранения документов, как CouchDB? IMO Document-ориентированное хранилище кажется идеальным для расширяемых объектов. Но я с ними не работаю и не имею необходимых данных о том, полезны ли они.

Только мои 2 цента. Надеюсь, это поможет.

...