Layout del progetto .NET Entity (architettura)

Question

Sto cercando di determinare il modo migliore per progettare un progetto .NET Entity Framework per ottenere un buon approccio a livelli. Finora l'ho provato in un gioco basato sulla navigazione in cui i giocatori possiedono e gestiscono pianeti. Ecco come li ho:

Sito Web

Questo contiene tutte le front-end.

C# Project - MLS.Game.Data

Questo contiene il file EDMX con tutti i miei mappature dei dati. Non molto altro qui.

C# Project - MLS.Game.Business

Contiene varie classi che io chiamo come PlanetManager.cs 'Managers'. Il gestore del pianeta ha vari metodi statici utilizzati per interagire con il pianeta, come ad esempio getPlanet (int planetID) che restituirebbe un oggetto codice generato da MLS.Game.Data.

Dal sito, farò qualcosa di simile:

var planet = PlanetManager.getPlanet(1);

restituisce un oggettopianeta dal dal MLS.Game.Data (generato dal EDMX). Funziona, ma mi dà fastidio perché significa che il mio front end deve fare riferimento a MLS.Game.Data. Ho sempre pensato che la GUI avrebbe dovuto solo fare riferimento al progetto Business.

Inoltre, ho scoperto che le mie lezioni di Manager tendono a diventare molto pesanti. Finirò con dozzine di metodi statici in loro.

Quindi ... la mia domanda è: come fanno tutti gli altri progetti ASP EF?

EDIT

Dopo un po 'di più, però, ci sono elementi aggiuntivi che mi preoccupano. Ad esempio, supponiamo di avere il mio oggetto Planet, che viene generato nuovamente dal codice della procedura guidata. E se fosse venuto il momento che il mio pianeta avesse bisogno di avere una proprietà specializzata, diciamo "Popolazione", che è un calcolo di qualche tipo basato su altre proprietà dell'oggetto Planet. Vorrei creare una nuova classe che erediti da Planet e poi restituirla? (Hmm, mi chiedo se le classi sono sigillate dalla EF?)

Grazie

Answer 1

si potrebbe provare le seguenti operazioni per migliorare le cose:

• Usa EF per andare a prendere DTOS nel vostro livello di Data, quindi utilizzare queste DTOs per popolare gli oggetti di business più ricchi nel vostro livello di business. L'interfaccia utente dovrebbe quindi solo fare riferimento al livello aziendale.
• Dopo aver creato gli oggetti business ricchi, è possibile iniziare a internalizzare parte della logica dalle classi gestore, eliminando efficacemente il livello aziendale.

Personalmente preferisco il modello più ricco al modello di gestore perché, come dici tu, si finisce con un carico di metodi statici, che inevitabilmente finiscono per incatenarsi all'interno di altri metodi statici. Trovo questo sia troppo disordinato e, cosa più importante, più difficile da capire e garantire la coerenza dei tuoi oggetti in un dato momento.

Se si incapsula la logica all'interno della classe stessa, è possibile essere più certi dello stato dell'oggetto indipendentemente dalla natura del chiamante esterno.

Una buona domanda, a proposito.

Answer 2

Non sono un esperto, ma che suona abbastanza buono per me. È simile a quello che ho nelle mie soluzioni, eccetto che unire il progetto EF al progetto di business. Le mie soluzioni non sono così grandi e i miei oggetti non richiedono molta intelligenza, quindi va bene per me. Anch'io ho un sacco di metodi diversi per ciascuna delle mie classi di helper statiche.

Se non si desidera che il livello di presentazione conosca il livello di accesso ai dati, è necessario creare alcune classi intermedie, il che probabilmente richiederebbe molto lavoro. Quindi, qual è il problema con la configurazione corrente?

Answer 3

IMHO, il layout corrente va bene. È perfettamente normale che l'interfaccia utente faccia riferimento al livello "Dati" come lo chiami tu. Penso che forse la tua preoccupazione sia dovuta alla terminologia. I "Dati" che hai descritto più spesso si riferiscono a un livello "oggetti aziendali" (BOL). Un layout comune sarebbe quindi quello di avere un livello di business logic (BLL) che è il tuo livello 'Managers' e un livello di accesso ai dati (DAL). Nel tuo scenario, LINQ alle Entità (supponendo che lo userai) è il tuo DAL. Un modello di riferimento normale sarebbe quindi: -

Riferimenti UI BLL e BOL. BLL restituisce BOL e DAL (LINQ alle entità).

Dai un'occhiata a this series of articles per maggiori dettagli.

Answer 4

Il layout sembra ok. avrei aggiunto una/strato di comune utilità

interfaccia utente Web
Affari Strato
DataObjects
Utilità

Answer 5

Per quanto riguarda la seconda domanda (dopo l'EDIT) se avete bisogno o volete aggiungere funzionalità ai tuoi oggetti EF puoi usare classi parziali. Fare clic con il pulsante destro del mouse sul file EDMX e selezionare il codice di visualizzazione.

Oppure, se ciò non è sufficiente, puoi abbandonare il progettista e scrivere le tue classi abilitate EF.

C'è una (breve) discussione di entrambe le opzioni qui - http://msdn.microsoft.com/en-us/library/bb738612.aspx

Answer 6

Vorrei aggiungere DTOs al vostro livello di business che sono rappresentazioni "oggetto muto" (vale a dire solo proprietà) delle entità che compongono la parte dati. Poi le vostre classi "manager" loro possono tornare, come ad esempio:

class PlanetManager 
{ 
    public static PlanetDTO GetPlanet(int id) { // ... } 
} 

e l'interfaccia utente in grado di trattare solo con lo strato BLL via pocos; il Manager (che chiamerei una classe "Mapper") gestisce tutte le traduzioni tra gli oggetti e il livello dati. Inoltre, se è necessario estendere la classe, è possibile avere una proprietà "virtuale" sull'oggetto DTO e farla tradurre dal Manager ai suoi componenti.

Answer 7

Per quanto riguarda la seconda domanda nella sezione "EDIT":

Se non mi sbaglio, le classi generate da EF non sono sigillati, e sono PARZIALI classi, così si potrebbe facilmente estendere quelli senza toccare direttamente i file generati.

La classe generato sarà:

public partial class Planet : global::System.Data.Objects.DataClasses.EntityObject 
{ 
... 
} 

modo da poter facilmente creare il proprio "PlanetAddons.cs" (o come volete chiamarlo) di estendere questa classe:

public partial class Planet 
{ 
property int Population {get; set;} 
... 
} 

Piuttosto pulito, eh? Non c'è bisogno di derivare e creare gerarchie di oggetti artificiali ....

Marc