Есть решение разбитое на следующие слои: DAO, DAL, Services Gui где,
DAO - здесь хранятся классы описывающие доменнные модели;
DAL - Generic Repository и его реализация;
Services - здесь у меня методы по типу следующего: IEnumerable
предвижу сразу вопрос чем Services отличается от Repository, в репозитории у меня базовые методы CRUD
void Create(Entity entity);
void Update(Entity entity);
void Delete(Entity entity);
IQueryable
в Services же у меня строются более сложные запросы: соединения, группировка например:
var _orders = получаем данные;
var _histories = получаем данные;
var orders = _orders.Join(_histories, o=>o.Id, h=>h.OrderId,(o,h)=>new OrderView
{
//Формируем необходимое представление
})
.ToList();
ну и т.п.
зависимости между проектами следующие:
DAO подключен в качестве reference в DAL, Services, Gui
DAL подключен в качестве reference в Services, Gui
Services подключен в качестве reference в Gui
Хочу проект сделать так что бы дальнейшая поддержка причиняла как можно меньше проблем.
Правильно ли я поступил разбив проект на более мелкие части, или я сделал так зря и необходимо слить все в один проект а разделение сделать на уровне директорий внутри решения и namespace
Буду премного благодарен за ссылки на литературу которую стоит почитать что бы прояснить для себя как правильно строить каркас приложения
Ответ
Есть самые разные способы проектирования приложения. Как я вижу вы пытаетесь использовать DDD. Этот паттрен достаточно универсален, но не является сильвербуллетом, а так же имеет очень много вариаций реализации, например CQRS+ES или DDD+Onion которые имеют свои назначения, а вместе с ним свои плюсы и минусы.
По мимо DDD и его вариаций, существуют такие архитектурные паттерны как EDA, SOA, NLayer и другие.
Что бы поддержка не причиняла больших проблем, нужно сначала выбрать правильную архитектуру, а это вопрос не только правильного выбора паттерна, но языка, стека технологий и многого другого. Сам же выбор зависит от решаемой задачи и различных условий.
Комментариев нет:
Отправить комментарий