Prima di tutto, le basi.
Applicazione a più livelli: presentazione, livello aziendale, database. È una vecchia applicazione .NET 2.0 (WSE + WinForms), un po 'più strettamente accoppiata di quanto mi piacerebbe, e il requisito è quello di aggiornarlo a un'architettura più recente, eliminando allo stesso tempo il design tutt'altro che ideale scelte fatte più di 10 anni fa (es. usate DTO invece di datatable / viste DB direttamente sul client ecc.)
Sto pensando di seguire il seguente disegno, a grandi linee:
- Creare una classe del livello della logica aziendale che includa tutte le logiche di business, le convalide ecc., utilizzando una classe di accesso ai dati per le operazioni CRUD.
- Esporre questo BLL utilizzando un livello di servizio WCF come wrapper per i suoi metodi.
- Consuma il servizio WCF dal nuovo client (probabilmente WPF).
Per centralizzare tutte le operazioni relative a WCF nel progetto client, creerò una classe helper che gestisce la connessione al servizio WCF e si comporta come una facciata per le operazioni di servizio.
Ora, allo stesso tempo, ci sarà una nuova applicazione Web (MVC) che utilizzerà alcune delle operazioni definite nella BLL. Tuttavia, a causa dell'esternalizzazione e di altri motivi che esulano dall'ambito di questa domanda, ciò che in particolare non voglio è che lo sviluppatore del controller MVC utilizzi (o addirittura conosca) ad es. %codice%. Al contrario, non vorrei che lo sviluppatore del servizio WCF fosse in grado di utilizzare BLLAssembly.WCFOnlyMethod() . Immagino che entrambi questi casi possano essere coperti utilizzando i simboli di compilazione condizionale nell'assieme BLL (ad esempio WEB_ONLY / WCF_ONLY), ma ovviamente ciò significa due diverse versioni di esso, uno per ciascun progetto.
Quindi la mia domanda è:
Given the fact that there will be a single BLL in order to maximize code reuse, what is the optimal approach for referencing the BLL from the WCF service and the MVC controller?
The WCF service will have a hard-reference to the BLL, that much I can say with relative certainty. Client-side, the helper class will have a reference to the WCF service interface, which will be implemented by the proxy. That way the WPF client is not affected by internal changes in the BLL, as it should be.
Should the MVC controller have a hard-reference to (its version of) the BLL assembly as well?
Should I use a WCF service for the MVC project, as discussed here (Is this breaking SOA?) or is that overkill? The production server(s) will be the same for both projects.
Should I have the MVC controller reference an interface, instead of the actual BLL assembly? I would still need to instantiate an actual class implementing that interface, of course, so somehow the assembly should be passed to the MVC project... or I could use a WCF service (see above).
Or should I abandon the notion of a common BLL between the projects altogether?
Grazie in anticipo per qualsiasi consiglio.