Uso AngularJs da molto tempo. Io e il mio team facciamo un grosso uso di servizi per recuperare le risorse remote come Users che stagista usa $http servizio quindi, fondamentalmente, per ogni entità, ho servizi che prelevano / memorizzano tale entità.
Stavo pensando perché l'entità stessa non dovrebbe essere in grado di farlo e i servizi dovrebbero essere completamente rimossi. Non so se sto andando in quella direzione, ma ho bisogno di conoscere l'opinione degli altri.
L'uso estensivo del "servizio" è indicativo di una cattiva OOP. Tuttavia, la natura dello sviluppo a volte rende inevitabili le classi di servizio, come nel tuo caso.
La tua entità utente non dovrebbe essere responsabile per la memorizzazione o il recupero stesso; conservare se stesso non viola OOP, tuttavia, viola molte buone pratiche architettoniche come la separazione delle preoccupazioni e il principio di responsabilità singola. Consentire a un oggetto di archiviarlo e recuperarlo automaticamente renderà l'applicazione molto fragile e difficile da mantenere.
Avrai bisogno di un servizio di archiviazione e recupero; tuttavia, etichettarlo semplicemente come un servizio è un po 'pigro. OOP parla di nomi che verbo; rendiamo questo servizio un po 'più OOP ...
Un oggetto che è responsabile solo di CRUD è chiamato repository. Dovrebbe non contenere qualcosa di diverso dai metodi CRUD. Se trovi che il tuo repository ha un metodo come GiveUserPermission stai violando il pattern del repository, non appartiene a questo; appartiene alla classe User o alla classe Mediator di Utente e Autorizzazione. Ogni entità dovrebbe avere il proprio repository. Un repository non dovrebbe essere responsabile per più entità. E ricorda, è per entità, non per tabella.
È irrilevante che il proprio repository ottenga i propri dati da un database o da una chiamata di riposo http; il resto della tua applicazione dovrebbe essere ignorante in questo dettaglio.
Nelle entità DDD non si caricano dal repository, che è responsabilità di un servizio Applicazione. È fatto in questo modo per mantenere le entità pure, senza effetti collaterali. In questo modo ottieni almeno due vantaggi: 1) sono più testabili e 2) le operazioni di comando sono riprovabili (questo combinato con il blocco ottimistico è un grande passo per la scalabilità).
Tuttavia, il front-end non è un candidato classico per il modello di progettazione tattica Aggregate (se si utilizza AngularJs come applicazione client anziché un'applicazione back-end nodejs). Quindi probabilmente applichi le regole aziendali sul lato server dell'applicazione, per motivi di sicurezza. Ciò significa che il front-end invia semplicemente i comandi all'applicazione back-end in cui si dispone di un aggregato che a sua volta cambia stato in base alle regole aziendali e non ha regole aziendali che devono essere applicate. Nel migliore dei casi, hai alcune regole aziendali duplicate per una migliore UX.
In conclusione, nel front-end non hai entrate / aggregazioni DDD, quindi puoi utilizzare qualsiasi modello di caricamento che desideri.
Leggi altre domande sui tag object-oriented encapsulation architecture object-oriented-design separation-of-concerns