Настройка шаблона репозитория в MVC

Я пытаюсь понять, как работает шаблон хранилища и как его можно реализовать в пользовательском шаблоне MVC.

Насколько я понимаю, репозиторий – это слой, который просто возвращает данные из класса сущности или сохраняет класс сущности на постоянный уровень.

Теперь я вижу это вот так:

В мой контроллер входит запрос на создание пользователя. Просто имя пользователя и пароль. Мой контроллер будет делать что-то вроде этого:

function CreateAction ( ) { $userRepo = new userRepository ( ); $user = new userEntity ( ); $user->setUsername('user'); $user->setPassword('123456'); $userRepo->create($user); } 

Тогда мой класс userRepository выглядит следующим образом:

 class userRepository { public function create ( User $user ) { $this->db->exec ( "INSERT INTO ... QUERY TO SAVE THE USER" ); } } 

И мой класс userEntity выглядит так:

 class userEntity { private $username; private $password; public function setUsername ( $username ) { $this->username = $username; } public function getUsername ( ) { return $this->username; } public function setPassword ( $password ) { $this->password = $password; } public function getPassword ( ) { return $this->password; } } 

Теперь первое, что мне кажется неправильным, это то, что я использую запрос внутри класса репозитория. Где я фактически сохраняю класс userEntity в базе данных? Итак, другими словами, где я могу выполнять фактические SQL-запросы? Я предполагаю, что правильным способом было бы вызвать DAO внутри метода create для репозитория. Но я все еще пытаюсь понять, как DAO действительно выглядит и насколько он отличается от «Модели» с точки зрения модели в шаблоне MVC.

Но кроме этого, является ли это правильным способом реализации шаблона репозитория?

Solutions Collecting From Web of "Настройка шаблона репозитория в MVC"

Ваш репозиторий гораздо больше похож на TableDataGateway для меня. Идея репозитория – это еще один слой поверх слоя отображения, который посредничает между объектами домена и базой данных. Он также служит хранилищем доменных объектов в памяти (что отсутствует в вашем примере) и может инкапсулировать Factory для создания новых Entities. Они часто также позволяют запрашивать образцы репозитория по спецификациям:

Схема последовательности репозитория от POEAA

Это довольно сложная модель. Вы можете найти хорошие рецензии о Репозитории в

Также проверьте образцы образцов, ориентированных на хорошее управление доменами

Да, это правильная реализация шаблона репозитория. Шаблон DAO часто также полезен, но нет ничего плохого в вашей реализации.

DAO – простой шаблон, который отделяет вашу логику персистентности от вашей бизнес-логики. Это создало бы операции CRUD, в то время как ваш объект будет содержать методы для вашей бизнес-логики, поэтому он разделяет ответственность за сопротивление вашего домена. Обычно я отправляюсь в DAO для отдельных объектов и репозиториев для агрегатов, что позволяет мне делать такие вещи, как productCatalogRepository.Update (), которые, в свою очередь, будут перебирать DAO продуктов и хранить их.