Strutturare una soluzione C # winforms

Question

Quindi sto riorganizzando una soluzione C # di winforms per aiutare il disaccoppiamento e renderlo più pulito e organizzato. La soluzione tiene traccia degli ordini di una piccola impresa, ecc. .

Finora ho suddiviso i progetti in

App.View : tutto il codice relativo alla GUI
App.Data : solo strutture dati e interfacce. Nessun altro codice di implementazione
App.BusinessLogic : tutto il codice della logica aziendale che non ha riferimenti alla GUI

Ho alcune lezioni che non riesco a capire dove appartengano. Per favore fatemi sapere cosa ne pensate di quale progetto dovrebbe andare ogni classe o se c'è un altro progetto che dovrebbe essere creato per questo.

1. Una classe che recupera le preferenze dell'utente da un database
2. Una classe che recupera i dati statici dal nostro server di dati statici e restituisce set di risultati di dati.
3. Una classe che riduce i diritti degli utenti
4. Una classe modello che archivia una tabella degli ordini
5. Una classe che invia messaggi di posta elettronica su un'azione dell'utente

Answer 1

In realtà, penso che tu abbia qualcosa di diverso da un'architettura tradizionale a strati. Normalmente, i modelli dei dati su cui lavora l'applicazione verranno mantenuti in un livello aziendale, insieme al codice per operare su di essi. Il tuo livello dati avrebbe sia i modelli di dati del tuo framework di persistenza che il codice per interagire con quel framework. Penso che questa potrebbe essere la fonte della confusione tra i luoghi suggeriti delle tue lezioni e la tua reazione ad essa basata sui tuoi commenti.

Da quel punto di vista tutto ciò che recupera o porta si trova necessariamente nel tuo livello di dati: accede ai dati in un archivio permanente. Ciò che recupera viene infine convertito in oggetti di livello aziendale su cui opera la logica aziendale. Le cose sono modelli concettuali - come una tabella di ordini - o le azioni commerciali appartengono al livello aziendale. Concordo con @Adron, forse, con la stessa confusione su dove (3) vada a seconda di cosa sia effettivamente.

Più specificamente:

1. Le preferenze dell'utente sono business oggetti, la cosa che recupera loro è un oggetto di livello dati.
2. I dati statici vengono associati a un'azienda oggetto (tabella o vista o qualcosa del genere), la cosa che accede all'esterno server è un oggetto livello dati.
3. Il diritto dell'utente è un oggetto business, la cosa che lo recupera è un oggetto livello dati.
4. Una tabella di ordini è un oggetto business
5. L'invio tramite e-mail è un'attività commerciale, pertanto l'elemento che invia alle persone è un oggetto commerciale

[EDIT] La mia architettura a 3 livelli generalizzata per (semplici) app Web

DataAccessLayer

Ciò includerebbe i miei TableAdapters e DataTables e Factory fortemente tipizzati che trasformano file delle mie DataTable in oggetti business in progetti pre-LINQ. Usando LINQ questo includerebbe il mio DataContext e le entità LINQ generate dal progettista.

BusinessLayer

Ciò includerebbe qualsiasi logica aziendale, inclusa la convalida e la sicurezza. In pre-LINQ questi sarebbero i miei oggetti business e tutte le altre classi che implementano la logica dell'applicazione. Usando LINQ queste sono le implementazioni di classe parziale delle mie entità LINQ per implementare sicurezza e validazione insieme a qualsiasi altra classe per implementare la logica di business.

Presentazione

Questi sono i miei moduli Web, sostanzialmente l'interfaccia utente dell'app. Includo alcune delle logiche di validazione nei moduli come ottimizzazione, sebbene queste siano anche validate nel BL. Ciò includerebbe anche qualsiasi controllo utente.

Nota: questa è la struttura logica. La struttura del progetto generalmente rispecchia questo aspetto, ma ci sono alcuni casi, come le connessioni ai servizi Web, che possono essere direttamente inclusi nel progetto Web anche se logicamente i componenti sono realmente nel BL / DAL.

Nota: probabilmente passerò a MVC su 3 livelli una volta che ASP.NET MVC sarà in produzione. Ho realizzato alcuni progetti personali in Ruby / Rails e mi piace molto il paradigma MVC per le app Web.

Answer 2

Hai specificato che App.Data dovrebbe contenere solo strutture di dati e interfacce, nessun codice di implementazione, il che va bene se vuoi farlo, ma che non ti lascia da nessuna parte per inserire il tuo codice di accesso al database tranne nella tua App.BusinessLogic montaggio.

Forse hai davvero bisogno di rinominare App.Data in App.Model (o qualcosa di simile) e avere un nuovo assembly App.DataAccess che parla al database (forse implementando un modello di repository). Fatto ciò, dividerei le cose in questo modo:

1. App.DataAccess
2. App.DataAccess
3. App.DataAccess
4. App.Model
5. App.BusinessLogic

Answer 3

Probabilmente andrei con

1. Dati
2. Dati
3. Dati, anche se non sono del tutto sicuro di cosa stia facendo la classe
4. Dati
5. BusinessLogic

Answer 4

1. - > App.Data
2. - > App.Data
3. - > App.BusinessLogic o App.Data - non sono sicuro di cosa significhi.
4. - > App.BusinessLogic
5. - > App.BusinessLogic