BG Development


Страници: (2) [1] 2   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Repository pattern
relax4o
Публикувано на: 08-02-2018, 04:02
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1979
Регистриран на: 04.04.07



Разработвам си един сайт с Ларавел и се зачудих кога и как е правилно да се имплементира Repository шаблона. В нета намирам какви ли не имплементации.

За пример давам следния случай, в който аз се чудя.
В момента имплементирам малка система за (да кажем) ЛС.

https://bitbucket.org/StefanTotev/repositorypattern/src
(Принципно има допълнителни навързани View Composer-и и ServiceProvider-и, но те не мисля, че са от значение за въпроса ми)

Качих набързо само файловете да се има на представа какво правя.

Главно въпроса ми е, правилно ли е да има сетъри(например setReaded/setUnreaded) в repository класа или те трябва да се имплементират в модела(който е ORM).
Какво пречи, ако направо се имплементират всички методи директно в модела?

Ето и пример и как го използвам във View Composer.
CODE

class MessageComposer
{
   private $messageRepository;

   public function __construct(MessageRepository $messageRepository)
   {
       $this->messageRepository = $messageRepository;
   }

   public function compose(View $view) {
       $view->with('totalUnreadMessages', $this->messageRepository->getTotalUnread());
   }
}

Това общо взето инжектира променливи във view-то.

И последен въпрос - хубаво ли е винаги да се ползва repository, когато се работи с данни?


--------------------
Бисери :D

QUOTE (oveRLuckEd)
Ползваш някоя нова версия на PHP, която е вече ооп ориентирана и заради това ти я изкарва тази грешка.


QUOTE (nbacool2)
Щом няма input полета, значи няма откъде да се направи SQL инжекция Very Happy
PM
Top
hristonev
Публикувано на: 08-02-2018, 08:37
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 391
Регистриран на: 19.09.17



Аз мога да дам мнение от към Симфони. Там модела ти е базова структура със сетъри и гетъри и никаква логика проста структура от данни (1:1 с таблицата в БД-то). Репозитори се ползва ако искаш да правиш някакви по специални извращения със заявките към базата. Да кажем някакви филтри, които няма как да получиш от простата структура на модела.
PMEmail Poster
Top
thrawn
Публикувано на: 08-02-2018, 08:49
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1653
Регистриран на: 17.01.17



Сам по себе си, репоситори патернът е утопия. Затова гледай на него в контекстът на конкретния обект с който ще работиш, без да търсиш "универсални" имплементации.

Абстракцията която трябва да представлява репоситорито трябва да представлява фабрика която да създава обекти (евентуално ползваща някакви критерии, да речем за търсене). И разбира се, да ги сериализира.

Та в репоситорито няма място за гетери и сетери. Просто няма какво да правиш с подобни методи.
В контекста на ЛС, можеш да реализираш метод send в репоситорито. Този метод трябва да приема поне един обект (съобщението) и евентуално получател/и (в зависимост от архитектурата на съобщението). Изобщо, в тази абстракция трябва да капсулираш CRUD операциите със съобщения.

Това мнение е било редактирано от thrawn на 08-02-2018, 08:50
PMEmail Poster
Top
kapitancho
Публикувано на: 08-02-2018, 09:13
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1120
Регистриран на: 26.02.05



Само един малък офтопик - няма форма READED. Правилното е READ (произнася се по друг начин само). Така че is_readed -> is_read


--------------------
®...¢↓"←—¬ªº±£™×÷⁄...©
PMEmail Poster
Top
escapeboy
Публикувано на: 08-02-2018, 14:33
Quote Post



Име: Никола Кацаров
Група: Потребител
Ранг: Редовен член

Мнения: 419
Регистриран на: 04.12.04



С trait няма ли да е по-добре?


--------------------
PMEmail PosterUsers Website
Top
relax4o
Публикувано на: 08-02-2018, 16:20
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1979
Регистриран на: 04.04.07



QUOTE (hristonev)

Аз мога да дам мнение от към Симфони. Там модела ти е базова структура със сетъри и гетъри и никаква логика проста структура от данни (1:1 с таблицата в БД-то). Репозитори се ползва ако искаш да правиш някакви по специални извращения със заявките към базата. Да кажем някакви филтри, които няма как да получиш от простата структура на модела.

Обърнах се към repository заради view composer-a(service provider). Понеже view-то ми е разделено на части и частта с навигацията се вика отделно от да речем inbox view-то. Самия view composer извиква конкретен composer - в моя случай MessageComposer, който праща определени променливи, в случая в навигацията да показва, че имам непрочетени съобщения, но също когато отворя вх. кутия също да ми показва колко непрочетени имам. И понеже едни и същи данни се викат на няколко места (composer-a и controller-a) реших да направя repository, за да капсулирам нужната логика на едно място.

QUOTE (thrawn)

Та в репоситорито няма място за гетери и сетери. Просто няма какво да правиш с подобни методи.
В контекста на ЛС, можеш да реализираш метод send в репоситорито. Този метод трябва да приема поне един обект (съобщението) и евентуално получател/и (в зависимост от архитектурата на съобщението). Изобщо, в тази абстракция трябва да капсулираш CRUD операциите със съобщения.


Добре, маркирането за прочетено съобщение къде трябва да го направя?
Ако да речем имам следния метод в репозиторито:

MessageRepository.php
CODE

public function read(Message $message) {
     $message->save(['is_readed' => 1]);
     return $message;
}


MessagesController.php
CODE

public function show(Message $message) {
     // С repository: $message = $this->messageRepository->read($message);
     // без $message->save(['is_readed' => 1]);
     return view('message.show', compact($message));
}

Какво пречи вместо read() в репозиторито, маркирането за прочетено съобщение да го направя директно в show() метода на контролера. Така или иначе получавам обект за конкретното съобщение.

QUOTE (kapitancho)

Само един малък офтопик - няма форма READED. Правилното е READ (произнася се по друг начин само). Така че is_readed -> is_read

Да ти кажа вчера се замислих и аз за тази форма. Благодаря за поправката.

QUOTE (escapeboy)

С trait няма ли да е по-добре?

Също е вариант, но не съм сигурен до колко ще е удобно използването на trait-ове в случая.


--------------------
Бисери :D

QUOTE (oveRLuckEd)
Ползваш някоя нова версия на PHP, която е вече ооп ориентирана и заради това ти я изкарва тази грешка.


QUOTE (nbacool2)
Щом няма input полета, значи няма откъде да се направи SQL инжекция Very Happy
PM
Top
thrawn
Публикувано на: 08-02-2018, 17:18
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1653
Регистриран на: 17.01.17



read е състояние на съобщението, не на хранилището. Така че, метод setRead/isRead е редно да има в обектът описващ съобщенията.

Работата на хранилището е да управлява сериализирането на съобщенията а не да управлява състоянието на отделните обекти. Демек, хранилището трябва да има метод update който да сериализира обектите (включително и състоянието read). A съобщението трябва да предоставя интерфейс чрез който да можеш да прочетеш/промениш неговото състояние.

Струва ми се, че бъркаш целта на репоситори-то.
PMEmail Poster
Top
relax4o
Публикувано на: 08-02-2018, 17:58
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1979
Регистриран на: 04.04.07



QUOTE (thrawn @ 08-02-2018, 17:18)
read е състояние на съобщението, не на хранилището. Така че, метод setRead/isRead е редно да има в обектът описващ съобщенията.

Работата на хранилището е да управлява сериализирането на съобщенията а не да управлява състоянието на отделните обекти. Демек, хранилището трябва да има метод update който да сериализира обектите (включително и състоянието read). A съобщението трябва да предоставя интерфейс чрез който да можеш да прочетеш/промениш неговото състояние.

Струва ми се, че бъркаш целта на репоситори-то.

Очевидно го бъркам icon_lol.gif За това се допитвам, за да се опитам да вникна в нещата. icon_lol.gif


--------------------
Бисери :D

QUOTE (oveRLuckEd)
Ползваш някоя нова версия на PHP, която е вече ооп ориентирана и заради това ти я изкарва тази грешка.


QUOTE (nbacool2)
Щом няма input полета, значи няма откъде да се направи SQL инжекция Very Happy
PM
Top
thrawn
Публикувано на: 08-02-2018, 18:19
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1653
Регистриран на: 17.01.17



Целта на репоситори патентът е да скрие детайлите по работата със сториджът. Например, работиш с база данни но в бъдеще предвиждаш да добавиш функционалност за работа с xml файлове или директно с файловата система.

Както казах, в абстракцията зад която ще скриеш конкретните имплементационни детайли трябва да реализирам само CRUD операциите с моделът (данните с който работиш).

Разбира се, можеш да разглеждаш setRead/isRead като част от CRUD (update) но не виждам особен смисъл в това. Особено ако имаш и други флагове или полета които би искал да обновяваш. Така че е по-добре да правиш промените на един пас (ъпдейт на целия обекти) отколкото да го правиш на части (поле по поле).

Това мнение е било редактирано от thrawn на 08-02-2018, 18:19
PMEmail Poster
Top
relax4o
Публикувано на: 08-02-2018, 20:30
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1979
Регистриран на: 04.04.07



QUOTE (thrawn @ 08-02-2018, 18:19)
Целта на репоситори патентът е да скрие детайлите по работата със сториджът. Например, работиш с база данни но в бъдеще предвиждаш да добавиш функционалност за работа с xml файлове или директно с файловата система.

Както казах, в абстракцията зад която ще скриеш конкретните имплементационни детайли трябва да реализирам само CRUD операциите с моделът (данните с който работиш).

Разбира се, можеш да разглеждаш setRead/isRead като част от CRUD (update) но не виждам особен смисъл в това. Особено ако имаш и други флагове или полета които би искал да обновяваш. Така че е по-добре да правиш промените на един пас (ъпдейт на целия обекти) отколкото да го правиш на части (поле по поле).

Мисля, че взех да схващам идеята и според разбраното установих, че в крайна сметка в моя случай въобще не ми трябва да използвам repository pattern. Поне не за съобщенията. Само добавям излишен слой върху нещата, който де факто не ми е нужен.

Благодаря много.


--------------------
Бисери :D

QUOTE (oveRLuckEd)
Ползваш някоя нова версия на PHP, която е вече ооп ориентирана и заради това ти я изкарва тази грешка.


QUOTE (nbacool2)
Щом няма input полета, значи няма откъде да се направи SQL инжекция Very Happy
PM
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (2) [1] 2  Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2018 | BG Development | All Rights Reserved
RSS 2.0