N-уровневая архитектура .NET: что мне делать с объектами Model? - PullRequest
8 голосов
/ 05 января 2012

Я создаю решение с нуля, используя ASP.NET Web формы C #.

Я обеспокоен объектами модели, поскольку не хочу создавать дубликаты наборов объектов модели в каждом слое.Как лучше всего использовать объекты Model в трехслойной архитектуре в Web Forms?

Структура, которую я имею в виду, следующая:

  • UI
  • BLL
  • DAL
  • Модель

Модель будет содержать все модели классов , которые можно использовать в каждом разделе слоев.Я подумал, что это будет полезно, так как каждый слой нуждается в доступе к объектам модели.Например:

  1. Пользовательский интерфейс вызывает метод в BLL, передавая объект модели, заполненный данными.
  2. BLL вызывает метод в DAL, проходя через объект, который сохраняется в базе данных и т.д..

Спасибо

Ответы [ 4 ]

8 голосов
/ 05 января 2012

Модели могут быть сквозной проблемой с вашими слоями, что является быстрым способом сделать это.Или вы можете создать интерфейсы для своих моделей так, чтобы вы могли просто добавить интерфейс в нечто вроде BLL - это, по крайней мере, перестает быть сквозным.

Это также зависит от того, являются ли ваши модели простыми контейнерами данных( модель анемичного домена ), или содержат поведение, такое как способность подтверждать себя или отслеживать изменения самостоятельно ( модель расширенного домена ).

Вы можете обнаружить, что вашDAL на самом деле состоит из двух частей: шаблонный, никогда не специфичный для кода приложения для связи с базой данных, и специфический для приложения код заполнения модели.У нас такая ситуация.Мы разделяем интерфейсы наших моделей, код DAL для конкретного приложения может использовать этот интерфейс для передачи и извлечения данных из модели, но «истинный» код DAL работает с необработанными данными.

5 голосов
/ 05 января 2012

В относительно небольшом приложении вы можете поделиться своим Domain Entities вплоть до Presentation layer, но помните о сопряжении, которое это вводит.

Если в вашей привязке к данным вы, кроме сущности типаCustomer со свойством Address со свойством StreetLine1 и StreetLine2, тогда все ваши слои будут тесно связаны между собой, и изменение в одном слое, вероятно, приведет к изменениям в других слоях.

Итак, ваше решениедолжно быть основано на масштабе вашего проекта и количестве связей, которые вы можете иметь.

Если вы выберете низкосвязанный дизайн, ваш BLL будет использовать ваш DAL для извлечения сущностей и использования этих сущностей для выполнения поведения.Затем BLL будет использовать Data Transfer Objects для перехода к вашему Presentation layer, поэтому между вашим presentation layer и вашим Domain Model.

нет никакой связи.
1 голос
/ 12 января 2012

посмотрите на мой ответ здесь: https://stackoverflow.com/a/7474357/559144 это обычный способ, которым я все делаю и работаю хорошо, не только для MVC и Entity Framework ... фактически в MVC модель может быть типом сущности, который только имеет некоторые поля, содержащиеся в реальных бизнес-объектах, определенных на нижних уровнях, это зависит от того, действительно ли вам абсолютно необходимы все поля на уровне пользовательского интерфейса или только некоторые из них для визуализации и ввода некоторых данных ...

0 голосов
/ 05 января 2012

В качестве связанной темы, пожалуйста, посмотрите этот связанный ответ , который я недавно опубликовал, чтобы избежать дублирования кода и правильной архитектуры в кроссплатформенной системе клиент / сервер.

У меня есть +1 к другим постерам в этой теме, так как это не полный ответ, просто полезная информация, связанная с вопросом.

ЛучшийС уважением,

...