Пожалуйста, помогите в выборе правильной архитектуры n-уровневого веб-приложения.

Question

Пожалуйста, помогите в выборе правильного способа использования сущностей в n-уровневом веб-приложении.В настоящий момент у меня есть следующая ассемблика:

1. Модель (пользовательские объекты) описывает поля классов, которые использует приложение.
2. Валидация проверяет целостность данных из пользовательского интерфейса, используя метод атрибутов отражения (проверяет данные во всех слоях).
3. BusinessLogicLayer - это бизнес-фасад для дополнительной логики и кэширования, которые используют абстрактных поставщиков данных из DataAccessLayer.

4. DataAccessLayer переопределяет поставщиков данных abstarct, используя контекст данных LinqtoSql и запросы Linq.И вот тут-то и возникает чувство, что я ошибаюсь ... Мой DataLayer прямо перед тем, как отправляет данные на бизнес-уровень, отображает (преобразует) данные, извлеченные из БД, в классы модели (пользовательские объекты) с помощью картографов.Это выглядит так:

   internal static model.City ToModel(this City city)
   {
       if (city == null)
       {
           return null;
       }
   
       return new model.City
       {
           Id = city.CountryId,
           CountryId = city.CountryId,
           AddedDate = city.AddedDate,
           AddedBy = city.AddedBy,
           Title = city.Title
       };
   }
   

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

Answer 1

Вы можете использовать свои объекты данных в своем проекте, если они являются POCO. В противном случае я бы создал отдельные модели, как вы сделали. Но держите их в отдельной сборке (не в проекте DataAccess)

Но я бы не выставлял их через веб-сервис.

Другие предложения

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

Первое, что я сделал, - попросил их удалить все слои и вместо этого использовать что-то вроде этого (требуется контейнер IoC):

• Core (содержит бизнес-правила и доступ к данным через orm)
• Спецификация (Отдельный шаблон интерфейса. Содержит сервисные интерфейсы и модели)
• Пользовательский интерфейс (может быть веб-сервис, winforms, webapp)

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

Вы уже используете ORM и задумывались ли вы об использовании блока проверки (FluentValidation или DataAnnotations) для проверки? Упрощает проверку ваших моделей во всех слоях.

Answer 2

Обычной практикой может быть отправка DTO от границы обслуживания (служба WCF и т. Д.), Но если вы напрямую используете свои «сущности» в своей модели презентации, я не вижу в этом никакой пользы.

Что касается предоставленного вами фрагмента кода, почему бы не использовать AutoMappter ? Это помогает избавиться от написания кодов карт котловой плиты и делает это для вас, если у вас есть набор соглашений.

Answer 3

Избавьтесь от модели сейчас, прежде чем удалить ее позже, потребуется рефакторинг всего приложения.Последний проект, над которым я работал, использовал эту архитектуру, и поддержание уровня DTO и отображений на уровне модели базы данных - огромная боль в заднице и не дает никаких полезных преимуществ.Одна из главных неприятностей заключается в том, что LinkToSql не поддерживает эффективно отключенную модель данных.Вы не можете обновить таблицу базы данных, создав новую сущность БД с первичным ключом, совпадающим с существующей записью, а затем вставьте ее в контекст данных.Сначала вы должны извлечь объект из базы данных, обновить его, а затем зафиксировать изменения.Управление этим приводит к очень неприятным методам обновления, чтобы отобразить все свойства из ваших DTO в ваши классы LinqtoSql.Это также нарушает всю модель отложенного выполнения LinqToSql.Даже не заводите меня на проблемы, которые это вызывает со свойствами родительских классов, которые являются коллекциями дочерних DTO (например, DTO клиента со свойством Orders, которое содержит коллекцию DTO заказов), управление этими отображениями действительно очень сложное,пришлось сделать несколько обширных оптимизаций, потому что получение нескольких сотен записей привело к тому, что LinqToSql сделал 200 000 обращений к базе данных (по общему признанию, также был некоторый довольно тупой код, но вы получили картину).

Единственная действительная причина дляИспользуйте DTO, если вы хотите иметь несколько подключаемых слоев доступа к данным, например LinqToSql и NHibernate для поддержки разных серверов БД.Таким образом, вы можете поменять доступ к данным позже, не меняя другие слои.Если вам не нужно этого делать, спасите себя от боли и просто используйте сущности LinqToSql.