MVC/MVP/MVVM - Come organizzare la business logic

Question

Questo post è simile a in MVC/MVP/MVPC where do you put your business logic?, ma sto cercando ulteriori dettagli. Ho acquistato nel modello il luogo in cui dovrebbe risiedere la maggior parte della logica aziendale. Tuttavia, il modello, per quanto ho capito, ha molto da fare al suo interno: gestione dello stato dell'applicazione, persistenza dei dati, repository, oggetti di trasferimento dati e probabilmente altre cose.

Possiedo un'applicazione con regole aziendali estremamente complesse. Quando l'utente tenta di eseguire una determinata azione in una vista, esistono circa 20 regole diverse che devono convalidare se tale azione deve essere consentita o se all'utente devono essere richieste informazioni aggiuntive. Mi piacerebbe codificare queste regole di business one-per-method in modo da supportare testabilità e documentazione. Queste regole dovrebbero essere in una classe di repository? Forse in un livello di servizi sopra i repository? Qual è la migliore pratica qui tenendo presente che sto usando una soluzione ORM come Linq a SQL, EF o ibernate?

Answer 1

Se si tratta di regole aziendali, le inserirò in una tabella di database in modo che siano facili da modificare.

Il codice stesso è quindi una regola aziendale stupida e non interessa il contenuto delle regole, solo la struttura del contenitore delle regole.

Per quanto riguarda i commenti sottostanti, se è necessario limitare il proprio approccio a uno incentrato sul codice per qualche altro motivo, va bene, ciò rende lo sviluppo del progetto molto più costoso.

Quanto più complesse sono le regole, tanto più si ottiene il vantaggio di averle basate su tabella anziché su hardcoded. Se non ci sei abituato, la parte difficile può essere la definizione di un modello per le regole. Dopo la costruzione del modello, lo sviluppo è semplice.

Answer 2

In primo luogo, non dimenticare che in MVP, hai la possibilità di mantenere lo stato nella vista, quindi è una cosa in meno che sta succedendo nel modello.

Gli approcci del repository e del livello di servizio potrebbero essere applicabili. Penso che sarei tentato di esplorare entrambi in parallelo usando un paio di app di test. Mentre vai, probabilmente avrai la sensazione che uno sia più adatto dell'altro, a quel punto puoi concentrarti sull'approccio giusto.

Potrebbe sembrare uno sforzo inutile, ma sarà molto meno dello sforzo di cambiare approccio una volta che lo sviluppo è iniziato sul serio.

Answer 3

Avere uno sguardo nel modo in cui CSLA.NET gestisce le regole di business potrebbe essere interessante: http://www.lhotka.net/cslanet/