Entity Framework и инкапсуляция

Question

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

Это также применимо там, где у меня есть список расширений, привязанных к сетке (telerik RadGrid), и я обрабатываю команду редактирования в сетке. Я хочу создать форму редактирования и передать ей объект Extension, где теперь я передаю форму редактирования ExtensionID и создаю свой объект в форме.

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

Answer 1

Это будет зависеть от вашего источника данных. Если вы извлекаете список учетных центров из базы данных, это будет одним из подходов. Если это короткий список предопределенных значений (например, Да / Нет / Возможно, то), то атрибуты свойств могут помочь. Если он должен быть более настраиваемым для каждой среды, то IoC или шаблон поставщика будут лучшим выбором.

Я думаю, что ваша проблема похожа на страницу специального поиска, которую мы делали в предыдущем проекте. Мы украсили наши классы сущностей и свойства атрибутами, которые содержали некоторые предопределенные «указатели» на методы значений поиска и их отношения. Затем мы создали один пользовательский элемент управления пользовательского интерфейса (например, страницу редактирования, описанную в вашем сообщении), которая использовала эти атрибуты для генерации выпадающих списков и списков текстовых полей с автозаполнением, динамически генерируя выражение LINQ, а затем выполняя его во время выполнения на основе что бы пользователь ни делал.

Это было выполнено с помощью в основном трех движущихся частей: A) атрибутов в объектах доступа к данным B) методов «фасада атрибутов» в промежуточном компиляции и генерации динамических выражений LINQ и C) пользовательского элемента управления пользовательского интерфейса, который вызывал наш методы обслуживания среднего уровня.

Иногда такие планы имеют неприятные последствия, но в нашем случае это сработало отлично. Украшение наших объектов атрибутами, а затем создание единого логического пути дало нам достаточно энергии, чтобы сделать то, что нам нужно было сделать, при этом минимизируя объем требуемого кода и полностью исключив любой шаблон. Однако этот подход был не очень настраиваемым. Скомпилировав эти атрибуты в код, мы тесно связали наше приложение с источником данных. В этом конкретном проекте это не имело большого значения, потому что это была внутренняя система клиента, и она соответствовала срокам проекта. Однако на «реальном продукте», реализующем логику с шаблоном Provider или использующем что-то вроде Castle Projects, IoC позволил бы нам ту же мощь с гораздо большей конфигурируемостью. Недостатком этого является то, что существует больше возможностей для управления, и больше, что может пойти не так с развертыванием и т. Д.