MVC - Creo strati "congiunti" quando si tratta di più modelli?

Question

MVC - Creo strati "congiunti" quando si tratta di più modelli?

Naviga le tue risposte

#1 da (8 voti)

6

Sono nuovo di MVC e dell'architettura dei diversi livelli e questo è ciò che ho attualmente:

2 modelli: utente, azienda

2 livelli di servizio: UserService, CompanyService

2 interfacce che estendono il livello del database dal livello di servizio: IUser, ICompany

2 livelli di database: UserDB, CompanyDB

Ecco lo scenario: una funzionalità che aggiornerà sia la tabella Utente che quella aziendale nel database. Se l'aggiornamento dell'azienda ha esito positivo e l'utente non è riuscito, eseguirò il rollback del database per la società. Quindi penso che abbia senso farlo in 1 metodo.

Se sì, dove metto questo metodo che gestisce 2 modelli? È normale creare UserCompanyDB nel livello del database e UserCompanyService nel livello di servizio solo per questo scopo? E anche IUserCompany .

Dato che sono nuovo a tutto, ci sono molte possibilità, potresti pensare che sto avendo degli equivoci sugli strati basati sul mio modo di pensare attuale? In tal caso, vorrei cogliere l'occasione per rettificare anche questo.

Oh e se aiuta, sto principalmente cercando di seguire l'esempio in questo link: link

design-patterns mvc layers

posta user3373225 31.01.2016 - 15:01

fonte

1 risposta

Leggi altre domande sui tag design-patterns mvc layers

Architettura del server per brevi burst di ~ 150 subquery paralleli CPU-heavy Come faccio a tenere traccia delle richieste di modifica dell'interfaccia utente minuscole / piccole in Agile?

score 8 · Accepted Answer

Nel modello di progettazione MVC, la parte Controller è responsabile della traduzione delle azioni dell'utente in modifiche delle varie classi del modello coinvolte in una funzionalità.

Non esiste una relazione uno a uno tra controller, viste e modelli. In particolare, se un'azione dell'utente richiede modifiche a più classi del modello, è responsabilità del Controller provvedere (e anche a occuparsi dei casi d'angolo in cui un errore di aggiornamento di un modello deve eseguire il rollback degli aggiornamenti ad altri modelli) . Per rendere possibile la gestione di questi casi angolari, è possibile utilizzare i modelli di progettazione dell'unità di lavoro. Con questo modello, gli aggiornamenti del database di più modelli possono essere inseriti in un'unica transazione di database.

La creazione di un modello, un servizio e una classe di database per una funzionalità che richiede due modelli altrimenti separati è non la strada da percorrere.