ASP.NET MVC DDD: зачем повторять один и тот же код 3 раза?

Question

[stud3nt]

Доброго времени суток!
Я изучаю ASP.NET MVC и планирую в скором времени написать достаточно сложный проект.
Недавно я задумался о том, как же должно быть устроено мое приложение, и начал искать различные подходы проектирования. В ходе поисков наткнулся на следующий туториал (
исходники из туториала).
Изучив исходники, я заметил, что в нем присутствуют абсолютно одинаковые интерфейсы (IRepositoryBase, IServiceBase, IAppServiceBase), а классы, реализующие эти интерфейсы, работают следующим образом: например, вызывается метод Add(entity) класса, реализующего IAppServiceBase. Этот класса вызывает аналогичный метод класса, реализующего IServiceBase, который вызывает тот же метод класса, реализующего IRepositoryBase.
Мне не понятно зачем все настолько усложнять.
Собственно вопросы: зачем 3 раза повторять код? является ли данный подход верным? какими подходами пользуетесь вы (желательно с примерами asp.net mvc) ?

Answer 1

[ArturNak]

Подходов на самом деле множество,а возможных реализаций этих подходов еще больше. В зависимости от задачи подход может отличаться. Поэтому надо исходить из задачи.

Answer 2

[Валерий Абакумов]

Добрый день!

Верным является такой подход, который решает поставленную задачу эффективно, быстро и просто. Моя деятельность связана с проектами по автоматизации бизнес-процессов заказчиков. В таких проектах лучше делить всю логику на несколько слоев: слой представлений (в частности, приложение на ASP.NET MVC, WPF, WinForms), слой бизнес-логики (отдельная библиотека, class library), слой доступа к данным (тоже отдельная библиотека).

Опишу пример.
В одном из своих личных проектов на ASP.NET используется как раз разделение логики на слои. Есть несколько проектов: MyApp.MVC, MyApp.DAL, MyApp.BL. Соответственно, общая схема работы такая: в контроллерах слоя MyApp.MVC идет обращение к методам из слоя MyApp.BL (слой бизнес-логики). Если методу из слоя MyApp.BL нужно поработать с данными БД, то он уже обращается к методам слоя работы с данными (MyApp.DAL). Слой MyApp.DAL уже непосредственно вытаскивает/добавляет/изменяет/удаляет данные. При этом слои не знают о конкретных реализациях методов, т.к. все базируется на интерфейсах и инверсии зависимостей (DI и IoC-контейнере, в частности - Ninject). В итоге что мы получаем:
1. Разделение ответственности (каждый делает только то, что ему нужно, т.е. каждый выполняет свою задачу).
2. Легкость сопровождения (нужно изменить логику выборки данных - например, изменить SQL-запрос. Все изменения коснутся только слоя MyApp.DAL, другие слои в этом случае менять не нужно и им будет "по барабану", что происходит внутри слоя MyApp.DAL).
3. Расширяемость компонентов (здесь я имею в виду, что можно взять слой MyApp.DAL и включить его в другое приложение).
4. Наглядность (код более чистый и последовательный).

Я уверен, что это не "панацея", и в других типах проектах (например, игры? сложные математические модели?) такая архитектура может принести больше вреда, чем пользы (как пример, "продирание" через интерфейсы).