Анемическая модель домена и объект ObjectDataSource

Question

Недавно я понял, что я создаю свои n-уровневые приложения с использованием Anemic Model, о которых многие утверждают, не является надлежащим способом OO делать вещи (и что это фактически анти-шаблон) ,

Так что теперь я пытаюсь применить проект, управляемый доменом.

Я использую objectdatasource для привязки элементов управления, таких как сетка, к моим бизнес-объектам. Я смущен относительно того, как я буду использовать objectdatasource с моделью домена. требует ли объект-источник данных анемичную модель?

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

Answer 1

Я думаю, что привязка данных вообще пород, хотя у меня нет большого опыта работы с ASP.NET. Это дает вам много преимуществ, поэтому не отказывайтесь от него слишком легко.

Ключом является разделение проблем. То, как вы обрабатываете данные, не имеет ничего общего с самой моделью домена, поэтому лучший дизайн - это специализированный Presentation Logic layer, который отображает модель домена в представления.

Это означает, что вы можете поддерживать нейтральную технологию Domain Model, чтобы вы могли подвергать ее множеству непредвиденных путей. Представьте, что в будущем вам будет предложено реализовать службу WCF или пакетное задание или богатый WPF/SL клиент на основе модели домена. Он должен иметь возможность обрабатывать такие непредвиденные требования, не перетаскивая множество особенностей, связанных с какой-либо конкретной технологией пользовательского интерфейса (например, ASP.NET).

Если у вас есть ViewModels или Презентационные Модели для каждого из Views, вы можете использовать databanding против этих моделей. Я не знаю, насколько хорошо это работает в ASP.NET, но оно работает как шарм как в ASP.NET MVC, так и в WPF, а поддержка для этого в настоящее время встроена в Silverlight 4 ...

Answer 2

Лично я не очень беспокоюсь об исключении настойчивости при оценке анемии объекта. Бизнес-поведение объекта должно быть ортогонально тому, является ли оно постоянным и как оно сохраняется.

Поведение должно быть связано с функциональностью, которая помогает решить коренную проблему. Я бы сосредоточился на том, что при проектировании объектов, которые являются более объектами переноса, и не беспокоиться о работе CRUD.