twitterfacebookrss

Архитектура. Часть 3. Ядро проекта

типовые решения архитектуры по

Выбор архитектуры в первую очередь зависит от опыта разработчика и во все остальные очереди — от книги Фаулера. (Шутка)

Часть 1
Часть 2

Когда проект начинался, я, конечно же, решил использовать многослойную архитектуру.
Техническое задание было вменяемое, что давало возможность заложить архитектуру изначально. Единственный вопрос заключался в том, как организовать бизнес-логику, или по Фаулеру– какое типовое решение выбрать.
Фаулер предлагает несколько вариантов, которые я смело, делю всего на два:

  • когда есть сложная бизнес-логика, то выбирается «модель предметной области»(domain-driven design).
  • когда нет сложной бизнес-логики – всё остальные типовые решения, типа “transaction script” или “active record”.

Соответственно, нужно отталкиваться от потребностей проекта, выбирая то типовое решение, или смесь решений, что необходимы для проекта.

В Проекте 1, никакой сложной логики не предполагалось, всё сводилось к манипуляции данными и конвертации их в различные состояния. Поэтому архитектура была весьма проста. Библиотек ядра (пространство имён CompanyName.ProductName.Core…) три:

  • .Core.Entities – библиотека объектов-сущностей, которые представляют собой одну запись таблицы (либо объекта предметной области) + методы, которые конвертируют сущность в различные форматы. Библиотека видна для уровня представления. (Более правильно такие объекты именовать value-object “объект — значение”).
  • .Core.DataProviders – библиотека, которая представляет собой набор статических функций, которые, в свою очередь, объединены в классы по признакам предметной области. Если говорить проще, то эта библиотека позволяет манипулировать данными внешним потребителям. В основном реализует CRUD+ немного специфики. Библиотека видна для уровня представления.
  • .Core.DataAccess – библиотека, в которой идёт вся драка с применением ado.net. Библиотека видна только для .Core.DataProviders.

Более наглядно — смотрим на картинку (откроется в том же окне):

transaction script Фаулер

1. Потребитель данных (в одном из наших случаев веб-сайт) говорит, дай мне список сущностей (тех самых из пункта 2) или добавь эту сущность, туда где вы их храните.
2. Класс-сущность, которой кидаются уровни друг в друга.
3. DataProvider имеет ссылки на библиотеки ядра.
4. Здесь, собственно мы видим псевдокод, который вызывает класс из DataAccess, который возвращает массив Object-ов. Затем эти object-ы конвертируются в бизнес-объекты и отдаются выше, на веб-сайт.

Плюсы архитектуры:

  • то, что она существует, описана, и единообразно используется всеми программистами. Это «дорожная карта» программистов.
  • отделение слоя представление от слоя данных.
  • принятие архитектуры позволяет генерировать исходный текст.

Минусы:

  • возложение обязанности на сущности конвертировать себя в различные форматы, привело к путанице между программистами – кто-то конвертировал в сущностях, кто-то в DataProviders. Мне кажется, более правильно, было бы создать отдельный бизнес-слой, где жили бы сущности и происходила конвертация. Также это был бы более устойчивый к изменениям вариант.
  • не уверен, но, мне кажется, что интерфейсные ссылки сделали бы связность между уровнями менее жесткой + позволили осуществлять unit-тестирование.

Итого:

Архитектура является одним из основополагающих аспектов при реализации проекта — опыт, системный подход, чтение и обмен информацией это всё что у нас есть для строительства наших воздушных замков.

Читайте далее:

- какие ошибки были допущены в проекте, и какие выводы из этого были сделаны.
- постраничная выборка в asp.net или подводные камни GridView.
- генератор кода или велосипедный маппер своими руками.

[WP-POST-SLIDER]
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс
Автор статьи: Александр Шибанов

Александр Шибанов IT - предприниматель с более чем 10 летним стажем в индустрии. Принимал участие в различных по сложности проектах, на позициях программиста и руководителя проектов. С 2011 - года индивидуальный предприниматель.

Комментарии: