Как создать многоуровневую архитектуру в .Net MVC more Сухой (сущность framework)

Question

В настоящее время я создаю большой веб-проект, пытаясь сделать все правильно, разбивая вещи на фасады, службы, хранилища DAO (хранилища) хелперов и т.д.

Кроме того, используя DI с Ninject

Теперь, может быть, это просто becuase это ближе к началу проекта, но он чувствует, как он принимает вечность только для установки простых вызовов в БД?

Каждый раз, когда я хочу совершить новый вызов или что-то делать, он берет написание 4 метода минимум через каждый из уровней обслуживания, передавая все пути назад и т. Д. Каждый раз, когда вы что-то меняете в слое db , вам необходимо скопировать изменение вручную через объекты домена, а также обновить методы, которые вручную конвертируют объекты DAO в объекты домена (используя частичный класс для принятия DomainObjects в конструкторе объекта DaoObject и метод ToDomainObject для каждого объекта DaoObject)

Пропуск через каждый DaoObject для преобразования его в объект домена в конце каждого чтения Метод DAO кажется беспорядочным.

Мы используем структуру сущностей, DBfirst. Есть ли что-нибудь умное, что мы можем сделать, чтобы сделать этот процесс более СУХОЙ или нам просто нужно подождать, пока не будет построена наша основная основа нашего приложения, и тогда все станет легче, потому что большая часть сантехники уже уложена и т. Д. И особенно это будет хорошо, когда вы хотите создавать новые сервисы, комбинируя существующие.

Частично повторное создание объектов DAO в слое Business Logic ощущается раздутым, НО я могу понять, что реальный способ подумать о том, что слой DAO фактически отображается на бизнес-уровень, он просто чувствует себя медленным по сравнению с использованием Context Designer. IE бизнес-уровень диктует, какие данные ему нужны, не заботясь о том, откуда он на самом деле.

Любая помощь будет с благодарностью оценена.

Answer 1

Одна вещь, которая определенно ускорит время, необходимое для добавления новых функций, использует AutoMapper для автоматического преобразования вашего DAO в объект домена. Нет более скучного ручного отображения свойств!

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

Answer 2

Посмотрите на возможности создания шаблонов T4. Он может использоваться для создания \ регенерации объектов на основе изменений в DAO.

Посмотрите на http://www.blogfor.net/2009/09/03/generating-business-layer-code-t4-against-a-linq-to-sql-dal/

и

http://imaginarydevelopment.blogspot.in/2010/01/t4-generates-my-business-objects-for-me.html

, чтобы получить некоторые идеи.