Jak správně vytvořit diagram komponent u NETTE aplikace

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Klainer
Člen | 42
+
0
-

Dobrý den,
mám na Vás dotaz z hlediska návrhy architektury systému.

Jak by jste správně vytvořili diagram komponent aplikace napsané v NETTE frameworku, rozdělen do N-vrstev.

Aplikace je rozdělena na Admin a Front modul, využívá Kdyby Doctrine, jsou zde entity a modely ve kterých se manipuluje s pomocí DAO se se samotnou databází.Aplikace komunikuje s vnějším světem i pomocí LinkedIn api (nainstalováno rozšíření, které je pak použito v presenteru).

Rád bych si v tomhle udělal jasno, jelikož mi některé vrstvy splývají do jedné.
Například nevím co konkrétně tvoří Service vrstvu, splívá mi s business, kde jsou zahrnuty v mém případě i entity.

Můj aktuální pravděpodobně špatný návrh je zde na obrázku. Budu rád za jakékoli doplnění. Chci vědět co konkrétně může být považováno jako servisní vrstva a co jako business
Obrázek

Děkuji za rady

Editoval Klainer (3. 12. 2014 6:54)

Azathoth
Člen | 495
+
0
-

asi jsem trochu zmaten pojmy. Co přesně je servisní vrstva a co má dělat?
Pokud service vrstva obsahuje services tak, jak je označuje DI, pak servisní vrstva=business logic vrstva.

Editoval Azathoth (4. 12. 2014 0:49)

Azathoth
Člen | 495
+
0
-

a možná by bylo dobré používat jiné označení pro služby než komponenty, protože ty jsou v nette něco trochu jiného.

Klainer
Člen | 42
+
0
-

Servisní vrstva co jsem hledal zapouzdřuje operace nad daným objektem,např v jedné metodě uděláš více nad ním více operací a nemusejí se týkat pouze jeho. Business Logic je zas podle toho co si myslím jen nějaký model nad danou entitou. Nejsem si tím 100% jist. Jinak chápu že komponenta je v NETTE taky jinší pojem, ale já beru diagram komponent ve smyslu UML tedy architektury systému. Díky za názor, snad se ještě někdo vyjádří a ujasní mi pojmy s dojmy :).

Azathoth
Člen | 495
+
0
-

hm, v tom případě servisní vrstva i business logic bude z hlediska mvc v modelu, třídy service logiky v sobě budou mít kompozicí třídy té business logiky, které potřebují. Snad je to to, na co se ptáš.

LeonardoCA
Člen | 296
+
+2
-

Na tvou otazku bez detailni znalosti tve aplikace neumim odpovedet.

Architektura aplikace je (mela by byt) nezavisla na pouzitych nastrojich (programovaci jazyk/framework/databaze) – mela by se odvijet od problemu, ktery resi. Tzn v zavislosti na slozitosti a rozsahu aplikace se muze architektura (vcetne poctu vrstev) hodne lisit a neexistuje nejake jedine a nejlepsi obecne reseni.

Mam jen tip na inspiraci – popis „ciste architektury“ http://blog.8thlight.com/…tecture.html

Editoval LeonardoCA (4. 12. 2014 11:47)

Klainer
Člen | 42
+
0
-

Díky za zajímavý článek. Jedná se o klasickou aplikaci v NETTE ve spolupráci s Doctirine. Tj mám složku s entitami, mám modely. Pak mám složky AdminModule FrontModule, zde jsou presentery,templaty,formuláře ve složkách. Model pak vypadá nějak takhle:

class Offers extends Nette\Object  {

    protected $em;

    protected $dao;

    public function __construct(\Kdyby\Doctrine\EntityManager $em)
    {
        $this->em = $em;
        $this->dao = $em->getDao(\App\Entity\Offer::getClassName());
    }

	//implementace funkcí save, delete, findById atd...

Pak je klasická hyearchie presenterů počínaje BasePresenterem, který pomocí DI načítá všechny modely. tj mám tam např:

/**
 * Base presenter for all application presenters.
 */
abstract class BasePresenter extends Nette\Application\UI\Presenter
{
     /** @persistent */
    public $locale;

    /** @persistent */
    public $backlink;

    /**
     * @var \Nette\Mail\IMailer
     * @inject
     */
    public $mailer;

    // DATA SERVICES

    /** @var \App\Offers @inject */
    public $offers;

následují pak konkrétní presentery jako OfferPresenter který dědí z BasePresenteru, atd..

a to je v podstatě všechno, je to základní aplikace. Ve které ještě používám např. nějaké vendor doplňky, data grid, linkedIn api…

Mno a nad tímto bych chtěl udělat nějakou vizualizaci v podobě architektury s využitím diagramu komponent.

Editoval Klainer (4. 12. 2014 12:12)

Šaman
Člen | 2666
+
0
-

Před pár dny jsem odpovídal na stejnou otázku, jen jinak formulovanou. Nette obecně model neřeší, jen poskytuje nástroje, které tvůj model může používat (NDb, DI).
To, na co se ptáš, možná popisuje klasická přednáška z jedné dávné poslední soboty, pojednávající o vrstvách modelu. Ale ta popisuje spíš ORM, než obecný model, i když v 80% případů za model budeš považovat právě ten ORM.

Pro představu úplně jiného modelu si představ třeba model, který počítá nějaký fyzikální jev, např. soustavu těles na pružinách. Nebo model popisující pravidla nějaké hry, dejme tomu jednoduché piškvorky. A vrstvu umělé inteligence, aby hráč mohl hrát proti počítači. Tady už si nevystačíš s ER diagramem, ale budeš potřebovat popsat úplně jinou logiku. Ale i to je modelová vrstva.

Editoval Šaman (4. 12. 2014 13:04)