Трехуровневое приложение на C# - куда поместить данные и бизнес-модели

Я создаю стандартное трехуровневое приложение на C#

1 консольное приложение для переднего плана/но я мог бы изменить это на ASP.NET веб-страница MVC

2 уровень бизнес-логики

3 Уровень данных с использованием Entity Framework, подключенный к базе данных SQL/но это может измениться на windows azure

Основной целью является отображение некоторых данных о клиентах.

Клиент, хранящийся в базе данных, имеет следующие поля - 

CustomerID
Firstname
Lastname
DateOfBirth
Othervalue1
Othervalue2
Othervalue3
Creationdate
Updatedate
IsDisabled //this represents "deleted" customers i.e. the app will never use deleted customers, but I want to keep them in the database anyway

В среднем ярусе, я только хочу 

CustomerID
Firstname
Lastname
DateOfBirth
Othervalue1
Othervalue2
Othervalue3
Updatedate

И в переднем конце для первого приложения я покажу только 

CustomerID
Firstname
Lastname
DateOfBirth

Как правильно реализовать N-уровневое приложение с точки зрения загрузки клиента из слоя данных (который может измениться) и использования этого клиента на среднем уровне, а затем на уровне презентации (который может измениться)?

Куда мне поместить модель клиента? Нужно ли мне больше одного? Нужен ли мне где-нибудь интерфейс ICustomer?

Детали проекта Проект будет разработано двумя командами, одна из которых находится в США, другая-в Восточной Европе, в ней будет от четырех до пяти членов команды.

Существует устаревший уровень доступа к данным, который этот проект не будет использовать. Вместо этого мы создадим новый с Entity Framework; нам нужно спроектировать и построить слой данных, который будет использоваться во всех новых приложениях (для этого приложения нам нужна только таблица customer и одна или две таблицы). Другие проекты добавят к этому слою другие таблицы.

Я использую DI чтобы ввести ICustomerRepository (см. Этот так вопрос ). Но реализовать репозиторий и единицы работы.

Моя забота заключается в надлежащем разделении слоев. В ближайшие несколько месяцев мы добавим много новых проектов, и новый уровень данных будет быстро расти. Мы также рассматриваем возможность перехода на Azure в какой-то момент, поэтому я хочу иметь возможность поменять местами уровень данных Entity Framework без необходимости переписывать бизнес-и интерфейсные слои.

1 4
c# design-patterns architecture n-tier

1 ответ:

У вас есть модель данных (схема БД), модель домена и модель представления.

Если ваша цель состоит в том, чтобы отделить слои, вы должны иметь различные классы, представляющие клиента в каждом из этих трех слоев (но смотрите статью @Joe упоминает в комментариях).

Ваша технология доступа к данным приведет к сопоставлению модели данных с моделью домена. Если вы используете Entity Framework, она предоставляет возможность сопоставления между этими двумя моделями.

Для отображения модель домена к модели представления, посмотрите на Automapper для отображения между объектами домена (например, бизнес-объектами) и моделями представления.

Обновить

Основываясь на вашей новой информации, я поделюсь тем, что бы я сделал. Это, конечно, не единственный правильный подход.

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

Дано новое программное обеспечение, построенное на базе устаревшей базы данных, вы должны знать о трех фактах:

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

Я бы сделал то же самое. следующие

  • создание объектов передачи данных (DTOs), представляющих структуру устаревшей базы данных.
  • используйте репозиторийи блок шаблонов работы , чтобы обеспечить доступ к DTO для уровня бизнес-объектов.
  • проектируйте уровень бизнес-объектов (средний уровень, классы которого часто называются сущностями) в соответствии с потребностями этого приложения. Не загрязняйте конструкцию объекта, основанную на структуре DTO (в конечном счете, структуре legacy DB).
  • используйте такую технологию, как Automapper, чтобы облегчить водопроводную работу по отображению между этими двумя слоями.
  • создание объектов пользовательского интерфейса (называемых моделями в терминологии MVC), представляющих данные, которые будет обрабатывать данный экран пользовательского интерфейса (представление в терминологии MVC).
  • В зависимости от того, насколько близко модели пользовательского интерфейса согласуются с бизнес-объектами (сущностями), вы можете использовать Automapper или просто заполнить их в пользовательском коде.

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

5