Форумы портала PHP.SU :: Версия для печати :: как Разбивать базу проекта на Domain и Application Logic

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:
скопировать код в буфер обмена

class user {
 
   private $databaseObj;
   private $viewObj;
 
   __consturct($DBObj, $ViewObj) {
       $this->databaseObj = $DBObj;
       $this->ViewObj = $ViewObj;
   }
 
 
   function validate_registration(array $user_fields) {
   
       /* ... Проверить првильность всех полей имя емайл пороль и т.п. */
 
      if ($fields_valid == true) {
          //Приложение не знает куда идут данные просто говорит враперу сохранить
          $status = $databaseObj->add_record("table_users", $user_fields_arr);
 
          if ($status == true) {
              $viewObj->load_page("registration_success.php", "Регистрация OK.")
          } else {
              load_page("system_error.php");
              email_admin();
          } 
      }
   }
 
   
   function read_user(int $user_id = '') {
 
      if (!empty($user_id)) {
            //Приложение не знает откуда данные просто говорит враперу считать их
            $user_fields_arr = $databaseObj->get_record("table_users", $user_id);
            $viewObj->load_page("user_edit.php", $user_fields_arr);
      } else {
            //Приложение не знает откуда данные просто говорит враперу считать их
            $user_fields_arr = $databaseObj->get_all_records("table_users");
            $viewObj->load_page("users_table.php", $user_fields_arr);
      }
   }
  
}

Обьяект $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 на другой движок все равно в любой базе нужно давать название таблице.