Organizzazione GUI, BLL, DAL in un progetto

Sto leggendo i livelli di applicazione e desidero utilizzare questo progetto nel mio prossimo progetto (c #, .Net). Alcune domande:

1. La separazione dei livelli avviene tramite spazi dei nomi? Project.BLL.Whatever, Project.DAL.Whatever

2. È più appropriato separare per layer, quindi componenti (Project.BLL.Component1) o per componenti, quindi layer (Project.Component1.BLL)

3. Per il mio DAL, questo livello è ulteriormente organizzato utilizzando classi diverse? Se tutte le chiamate al database vengono inserite in una singola classe, non esiste alcuna organizzazione. Sarebbe meglio dividerli con classi o spazi dei nomi diversi?

4. Le classi DAL sono in genere statiche? Sembra ingombrante istanziare un oggetto DAL prima di chiamare ogni volta uno dei suoi metodi.

Qualsiasi altro consiglio per fare le cose nel modo giusto con questi livelli sarebbe apprezzato.

1. Sì. E anche assemblee.
2. Separerei per strati, quindi per componenti.
3. Sì. Esistono diversi approcci a questo, ma avrei un IDatabaseService (astraggendo i vari modi in cui viene chiamato il database - questo può quasi essere una mappatura diretta di ExecuteScalar / ExecuteNonQuery / ExecuteReader) e quindi varie classi di accesso ai dati che partizione per tipo di dati. Ad esempio, potresti avere una classe UserDataAccess che avrebbe semplici metodi CRUD che creano / modificano / eliminano oggetti utente. Un altro approccio sarebbe quello di avere un oggetto Utente che ha il CRUD incorporato proprio dentro.

4. No. Questo rende molto più difficile il test unitario. È necessario utilizzare l' iniezione delle dipendenze per passare dipendenze al costruttore di ciascuna classe di accesso ai dati (come un IDatabaseService). Passeresti quindi gli oggetti di accesso ai dati negli oggetti business, in questo modo:

   BusinessObject businessObject = new BusinessObject (new DataAccessObject (new DatabaseService ())); businessObject.PerformOperation ();

Ogni oggetto business potrebbe richiedere più oggetti di accesso ai dati. Il tuo codice GUI userebbe anche uno o più oggetti business. Alcuni oggetti business potrebbero non aver bisogno di alcun oggetto di accesso ai dati ma non dovrebbero mai usare direttamente IDatabaseService.

Per le domande 1 e 2 vai con le risposte di Matthew.

Ho trascorso molto tempo cercando di capire il modo migliore per strutturare il DAL delle applicazioni desktop. E il modo migliore dipende davvero dalle esigenze dell'applicazione. In una delle mie app ho intrapreso la strada di avere una classe DA per ogni tabella di database, che si è registrata con una classe DataProvider centrale (cioè singleton) e ha gestito il CRUD. Ogni classe DA potrebbe quindi decidere se desidera memorizzare nella cache tutti i dati della tabella nella RAM o meno (prestazioni!) E / o se doveva avere la capacità di attivare aggiornamenti automatici dei client in altri client in esecuzione su altri computer (pensa a più utenti concorrenza). Ciò semplifica l'aggiunta di nuove classi DAL, poiché tutto ciò che devono fare è conformarsi all'interfaccia di registrazione.

Non tutti i DAL hanno bisogno di questo tipo di funzionalità, ma ho imparato che l'approccio stesso (vale a dire il fornitore di dati singleton e le semplici classi DAL con registrazione statica) mi ha reso la vita molto più semplice quando ho iniziato ad aggiungere nuove classi.

Non consiglierei assolutamente di costruire il CRUD in classi di livello superiore, a meno che questa non sia un'applicazione molto semplice. Il DAL è un'astrazione della memorizzazione dei dati. Se in futuro deciderai di cambiare la tua memoria di dati (anche se è solo per usare MySQL invece di MS SQL), ne sarai molto grato. Inoltre: gli oggetti BLL dovrebbero essere strutturati in base alle loro relazioni logiche aziendali. Gli oggetti DAL sono strutturati in base ai tipi di contenitori di stoccaggio che rappresentano. Le differenze possono essere drammatiche.

Non NON rendere il vostro classi DAL statico. Ciò che guadagni nella velocità di codifica perderai molte volte in termini di testabilità e flessibilità.