MVVM, BusinessLogic, Entities, DTO и связывая все это вместе

Question

Я работаю над новым проектом и размышляю над структурой моего приложения.

Технические характеристики:

• Несколько возможных клиентов (по крайней мере, рабочий стол на основе WPF заявка)
• BusinesLogic, который будет (хотя бы частично) выставлен третьим лицам
• DataAccess и объекты будут создаваться с помощью LLBLGen Pro V3

Существует множество вопросов по СО, связанных с этими (или связанными) проблемами. Собирая осколки здесь и там, я пришел к этому:

• Отдельный DAL, включая все созданные объекты
• A BLL
• Тонкая служба WCF, которая в дополнение к этому превращает указанные объекты в DTO (с использованием, скажем, Automapper)
• Клиент на основе WPF, использующий MVVM

Несколько дополнительных размышлений:

Все сущности находятся в DAL и известны только BLL. Представление не должно знать сущности, потому что DTO возвращается сервисным уровнем. Поскольку Presentation использует MVVM, DTO необходимо преобразовать в ViewModel.

Правильно ли я заявляю, что сущности не должны быть в общей сборке, на которую ссылается Presentation, а также BLL? Это относится к моему более старому проекту, в котором не участвуют ни WCF, ни WPF. Объекты находились в общей сборке, и BLL возвращал эти объекты, которые были напрямую связаны с элементами управления в презентации. На этот раз, хотя использование уровня обслуживания требует использования DTO для транспорта, таким образом, клиентам больше не нужно знать сущности, только DTO.

Дополнительные размышления: кто отвечает за создание DTO? Это просто вид транспорта, так что я думаю, что слой обслуживания.

Конкретный вопрос: это хороший подход? Поскольку это немного похоже на сверхинжиниринг, я уже сопоставляю свою модель базы данных с сущностями, эти сущности с DTO, а с ViewModels, и мне кажется, что это много накладных расходов.

Answer 1

Интересно, что вопрос рядом с этим вопросом в «активной» группе тега «Architecture»: .NET N-Tier Architecture: Что мне делать с объектами Model? и, кажется, ему было уделено гораздо больше внимания, чем этому, несмотря на то, что он очень похож.

В любом случае, не особенно в отношении .Net / WCF / WPF, все зависит от того, к какому типу гибкости вы стремитесь (или от ваших требований). Для меня нет ничего плохого в том, что вы делаете, и, в общем и целом, ИМХО, это самый умный подход, так как он освобождает вас от жесткости хранилища данных.

Помните, что если вы разрешаете внешним системам подключаться к вашей (например, через веб-API), вы должны , а не выставлять свой DAL. Даже BLL должен быть заключен в тонкий слой, чтобы вы могли абстрагироваться от конкретных потребностей транспортного уровня (чего и пытается достичь WCF, но этого может быть недостаточно, если у вас есть особая бизнес-логика для определенного транспортного канала - ключи API, и др.).

Наибольшим преимуществом является возможность настраивать ваши DTO в зависимости от вызываемых сервисов. В качестве примера рассмотрим веб-API LinkedIn. Они позволяют клиентам «запрашивать» данные, которые ему нужны, в любой момент времени и формировать конкретное представление набора данных, адаптированное к его потребностям, уменьшая использование полосы пропускания (для каждой службы API клиент не получает весь набор данных, просто конкретное мнение, которое оно запрашивает). Это веб-пример, но шаблон дизайна может также применяться к толстым клиентам.

Что касается производительности, то, безусловно, будет иметь место преобразование сущностей в DTO для просмотра объектов и т. Д. Но сначала проверьте, не связана ли производительность вашей системы с другими факторами (база данных, память, многопоточность и т. Д.). Опция DTO может быть даже быстрее, в зависимости от того, как вы строите свои сервисы, поскольку вы можете посылать намного меньше информации по сети. Вероятно, более важно тщательно спроектировать свой BLL, чтобы вы брали объект в DTO для обсуждения объекта. То же самое относится ко всем остальным слоям в вашей системе (услуги по представлению и т. Д.).