Форумы портала PHP.SU » » Объектно-ориентированное программирование » как Разбивать базу проекта на Domain и Application Logic

Страниц (1): [1]
 

1. ВеликийПрограмист - 21 Сентября, 2017 - 09:34:05 - перейти к сообщению
Я в замешательстве книгу Domain Driven Design Эванса я не читал но вижу в статьях о ней что он предлогает разбить программу на 4 слоя

Presentation Layer
Application (Service) Layer
Domain (Business) Layer
Data Storage Layer

Есть еще статья эта идея не нова ИМХО есть статья Multitier architecture на википедии об том же самом, только вот одно но такое деление это будет соответствовать принципам ООП?

Как это реализовать, а именно разбить на Application и Domain слои есть какие-то примеры?
И зачем нужно Data Storage Layer понятно чтобы можно было легко поменять базу данных, но можно же сделать Wrapper зачем целый отдельный механизм заталкивания в базу какой в этом смысл?
2. Bio man - 22 Сентября, 2017 - 00:23:27 - перейти к сообщению
ВеликийПрограмист пишет:
это будет соответствовать принципам ООП?
Если под ООП подразумевается ООПрограммирование, то, чтобы это было ООП, нужно соблюсти всего 2 условия - инкапсуляция и абстракция.
Если ООПроектирование, то это очень философский вопрос, однозначного ответа нет.
Но такая многослойная архитектура довольно распространена.
ВеликийПрограмист пишет:
Как это реализовать, а именно разбить на Application и Domain слои есть какие-то примеры?
http://www[dot]elisdn[dot]ru/blog/104/do[dot][dot][dot]tities-modelling
ВеликийПрограмист пишет:
И зачем нужно Data Storage Layer понятно чтобы можно было легко поменять базу данных, но можно же сделать Wrapper зачем целый отдельный механизм заталкивания в базу какой в этом смысл?
По хорошему, твой код ничего не должен знать о том, как и где хранятся данные, и как их от туда доставать. Вся эта магия должна быть заключена в 1 месте - в репозиториях. Репозиторий это по сути фасад над хранилищем данных, который предоставляет простой и удобный интерфейс для доступа к данным.
3. ВеликийПрограмист - 27 Сентября, 2017 - 12:03:08 - перейти к сообщению
Bio man пишет:
По хорошему, твой код ничего не должен знать о том, как и где хранятся данные, и как их от туда доставать. Вся эта магия должна быть заключена в 1 месте - в репозиториях. Репозиторий это по сути фасад над хранилищем данных, который предоставляет простой и удобный интерфейс для доступа к данным.


Он не должен знать, но он должен отправлять их на хранение к примеру когда новый клиент зарегистрировался вся validation делается на уровне приложения, но потом то приложение должно дать команду сохранить эти данные, пускай оно не знает как это будет осуществленно дальше, но команда исходит от преложения.

PHP:
скопировать код в буфер обмена
  1. class user {
  2.  
  3.    private $databaseObj;
  4.    private $viewObj;
  5.  
  6.    __consturct($DBObj, $ViewObj) {
  7.        $this->databaseObj = $DBObj;
  8.        $this->ViewObj = $ViewObj;
  9.    }
  10.  
  11.  
  12.    function validate_registration(array $user_fields) {
  13.    
  14.        /* ... Проверить првильность всех полей имя емайл пороль и т.п. */
  15.  
  16.       if ($fields_valid == true) {
  17.           //Приложение не знает куда идут данные просто говорит враперу сохранить
  18.           $status = $databaseObj->add_record("table_users", $user_fields_arr);
  19.  
  20.           if ($status == true) {
  21.               $viewObj->load_page("registration_success.php", "Регистрация OK.")
  22.           } else {
  23.               load_page("system_error.php");
  24.               email_admin();
  25.           }
  26.       }
  27.    }
  28.  
  29.    
  30.    function read_user(int $user_id = '') {
  31.  
  32.       if (!empty($user_id)) {
  33.             //Приложение не знает откуда данные просто говорит враперу считать их
  34.             $user_fields_arr = $databaseObj->get_record("table_users", $user_id);
  35.             $viewObj->load_page("user_edit.php", $user_fields_arr);
  36.       } else {
  37.             //Приложение не знает откуда данные просто говорит враперу считать их
  38.             $user_fields_arr = $databaseObj->get_all_records("table_users");
  39.             $viewObj->load_page("users_table.php", $user_fields_arr);
  40.       }
  41.    }
  42.  
  43. }


Обьяект $databaseObj это простенький wrapper для базы данных MySQL в котором есть generic метод add_record(string $table, array $fields) {...} который данные и добавит в указанную таблицу и даст return true;

1. Можно ли считать generic wrapper $databaseObj полноценным Data Storage Layer или он должен быть чем то большим чтобы так называться?

2А. Приложение знает название таблицы table_users где хоранятся данные, это нарушает правило что оно не должно знать где данные храняться и как?

Если бы я название таблицы перенес из приложения просто бы команду $storage_layer_obj->add_new_user($user_fields_arr); то мне бы пришлось действительно создавать сложный Data Storage Layer с кучей кода какой в этом смысл?

2Б. Я могу подключить одновременно воторую базу если у меня есть этот отдельный слой и просто дать её в другом обьекте и все не надо менять код приложения это плюс.

Но знание приложением название таблицы чему мешает? Ведь допустим я преешел с MySQL на другой движок все равно в любой базе нужно давать название таблице.
4. Bio man - 29 Сентября, 2017 - 15:00:33 - перейти к сообщению
В рамках DDD, Application layer не знает деталей хранения данных.
Application layer это сервисы, которые производят какие-то действия над твоими объектоми модели.
Data Storage Layer - это репозитории, которые используются в сервисах.
Код, который ты привел, не вписывается никаким боком в DDD, это и не сервис, и не репозиторий. Больше похоже на контроллер, и то сложно это назвать контроллером.

И что такое generic wrapper?
Я похоже отстал от сегодняшних реалий ))

Разберись сперва с базовыми концепциями DDD, потом приходи.
(Добавление)
Почитай цикл статей по ссылке, которую я привел выше.
Там доходчиво описывается, что такое доменная модель, сервисы и репозитории.
5. LIME - 30 Сентября, 2017 - 05:48:14 - перейти к сообщению
ВеликийПрограмист оно тебе надо?
Bio man ты че выделываесся?
типа композиция против наследования?
ой... я тя умоляю
угомонися ...тоже мне тру солид
(Добавление)
ВеликийПрограмист пока забей
хорошо что думаешь но пока забей
(Добавление)
Bio man если бы ты че дельное сказал я бы молчал
6. Bio man - 30 Сентября, 2017 - 16:26:13 - перейти к сообщению
LIME пишет:
Bio man если бы ты че дельное сказал я бы молчал
здаров.
скажи че дельное, обсудим. я за дебаты. свою точку зрения не отстаиваю, потому готов услышать мысли оппозиции ))
и да, я за SOLID, за правильное наследование, хоть это к теме и не относится.
и я не понимаю, что тебя так смутило!
LIME пишет:
ВеликийПрограмист пока забей
полностью согласен, рано пока в эти дебри лезть.

 

Powered by ExBB FM 1.0 RC1