MVVM, BusinessLogic, Entities, DTO и связывание всего этого вместе
Я работаю над новым проектом и обдумываю структуру своего приложения.
Технические характеристики:
- несколько возможных клиентов (по крайней мере, рабочий стол на основе WPF
применение) - BusinesLogic, которая будет (по крайней мере частично) раскрыта
третьим лицам - DataAccess и сущности будут генерироваться с помощью LLBLGen Pro V3
Существует множество вопросов о том, как решать эти (или связанные с ними) проблемы. Подбирая кусочки и куски здесь и там я пришел к этому:
- отдельный DAL, включающий все сгенерированные сущности
- A BLL
- тонкий сервис WCF поверх этого превращает указанные сущности в DTO (с использованием, скажем, Automapper)
- клиент на основе WPF, использующий MVVM
Несколько дополнительных размышлений:
Все сущности находятся в DAL и известны только BLL. Представление не нуждается в знании сущностей, поскольку DTO возвращается servicelayer. С Презентация используется в MVVM, ДТО нужно быть преобразована в модель представления.
Правильно ли я говорю, что сущности не должны быть A в общей сборке, на которую ссылается Presentation, а также BLL? Это имеет место в более старом моем проекте, в котором не участвуют ни WCF, ни WPF. Сущности находились в общей сборке, и BLL возвращал эти сущности, которые были непосредственно привязаны к элементам управления в представлении. На этот раз, однако, использование servicelayer гарантирует использование DTO для транспортировки, таким образом клиентам больше не нужно знать сущности, только DTO.
Дополнительное размышление: кто отвечает за создание DTO? Это просто вид транспорта, так что я бы предположил, что сервис-Лайер.
Конкретный вопрос: это хороший подход? Потому что он чувствует себя немного как излишнего усложнения вещей, я уже отображение моей модели базы данных организаций, лица, в ДТО и с ViewModel, и что чувствует, что это огромные расходы.
1 ответ:
Интересно, что рядом с этим вопросом в группе" active "тега"architecture" стоит вопрос .NET N-Tier Architecture: что делать с объектами модели?И, кажется, она привлекла гораздо больше внимания, чем эта, несмотря на то, что была очень похожа.
В любом случае, не конкретно в отношении .Net/WCF/WPF, все зависит от типа гибкости, к которой вы стремитесь (или от ваших требований). Для меня нет ничего плохого в том, что ты делаешь и делаешь., в целом и имхо, самый умный подход, поскольку он освобождает вас от ригидности хранилища данных.
Помните, что если вы позволяете внешним системам подключаться к вашим (например, через веб-API), вы должны абсолютно не выставлять свой DAL. Даже BLL должен быть обернут в тонкий слой, чтобы вы могли абстрагировать конкретные потребности транспортного уровня (чего пытается достичь WCF, но может быть недостаточно, если у вас есть специальная бизнес-логика для конкретного транспорта channel-API ключи и т.д.).Наибольший выигрыш - это возможность настраивать свои DTOs в зависимости от вызываемых служб. В качестве примера рассмотрим веб-API LinkedIn. Они позволяют клиентам "запрашивать" данные, которые им нужны в любой момент времени, и строить определенное представление набора данных, адаптированное к их потребностям, уменьшая использование полосы пропускания (для каждой службы API клиент получает не весь набор данных, а только определенное представление, которое он запрашивает). Это веб-пример, но шаблон дизайна может также применяться к жирным клиентам.
Что касается производительности, то, несомненно, будет иметь место влияние при преобразовании сущностей в DTOs для просмотра объектов в etc. Но сначала проверьте, не связана ли производительность вашей системы другими факторами (база данных, Память, потоковая передача и т. д.). Опция DTO может быть даже быстрее, в зависимости от того, как вы создаете свои сервисы, так как вы можете отправлять намного меньше информации через сеть. Вероятно, более важно тщательно разработать свой BLL, чтобы вы принимаете во внимание разговор сущности с DTO на сущность. То же самое относится и к любому другому слою в вашей системе (сервисы для презентации и т. д.).
Comments