LINQ a SQL: logica aziendale in un altro assembly?

Question

LINQ a SQL: logica aziendale in un altro assembly?

#1 da (2 voti)
#2 da (2 voti)
#3 da (1 voti)

4

Quindi sto provando la mia mano a questa domanda di applicazione a livelli con ASP.NET 4. Il software che ho sviluppato è un incubo di manutenzione e non è molto ben organizzato. Ho fatto un po 'di ricerche sul web e non riesco a trovare un esempio di ciò che sto cercando qui. Qualcuno si prega di scegliere questo design a parte.

My Data Access Layer sarà un assembly con LINQ to SQL.

Avrò un livello di logica aziendale che fa riferimento all'assieme DAL e fa ciò che fanno le BLL. Cose molto generali e di base.

Poi avrò una classe di oggetti business che ne fa parte relativa ai dati, ma è di tipo più "di lavoro" - come la generazione di documenti, ecc.

Il sito web interagirà con la BLL e gli oggetti di business.

Quindi:

    DAL
     |
     |
     |
    BLL----------BO
     |           |
     |           |
     |           |
    Web----------|

Sto facendo in modo troppo complicato?

Dovrei semplicemente inserire la mia logica di business proprio lì con le classi LINQ nel DAL? Non sono sicuro di come un DataContext possa funzionare in un assembly separato con classi che ereditano dalle classi LINQ. Pensieri?

c# asp.net linq

posta Mark Williams 07.10.2011 - 23:04

fonte

3 risposte

Leggi altre domande sui tag c# asp.net linq

Discussione disaccoppiamento Prototipo.js è ancora rilevante?

score 2 · Answer 1

Funziona bene. Fare riferimento e consumare DataContext dal DAL non è diverso rispetto a qualsiasi altro tipo di classe.

Tendo a creare le mie classi che rispecchiano le classi LINQ (di solito come entità WCF) invece di provare a estendere direttamente le entità LINQ. C'è un sovraccarico nel mantenere gli oggetti LINQ troppo a lungo, potrebbe essere un problema per te in un ambiente basato sul web se stai mantenendo gli oggetti solo per una richiesta / risposta.

Ho anche visto DataContext definiti nel proprio assembly, quindi funzionalità specifiche dell'applicazione innestate su entità LINQ mediante metodi di classe parziale e / o di estensione. Funziona bene, a condizione che DataContext / Entities non cambino in modo inaspettato e critico.

score 2 · Answer 2

L'articolo The Onion Architecture mi ha ispirato molto per quanto riguarda le architetture stratificate.

In base a ciò, definire le interfacce di servizio e repository nel progetto BLL. Le implementazioni di questi sono mantenute in un progetto di implementazione del servizio separato (chiamalo DAL se lo desideri). Il tuo progetto web fa riferimento a entrambi e inietta le implementazioni nella BLL. Il BLL non fa riferimento a nessuno degli altri e contiene solo il codice del livello di servizio, le entità aziendali e le interfacce di servizio e repository.

Si potrebbe dire che il progetto web sta configurando il BLL (modello) con opportune implementazioni di servizio.

score 1 · Answer 3

Questo DAL e BLL mi danno un certo mal di testa :-). Dal mio punto di vista, ti suggerirei di imparare ASP.NET MVC, è un sistema molto più organizzato e facile da mantenere. È possibile avere un assembly diverso per gli oggetti del dominio e l'interfaccia in un altro. La cosa migliore di questo è che non è necessario gestire troppe cose per ottenere un'applicazione accoppiata. Provaci e io sono sicuro, ti piacerà.