Layout del progetto .NET Entity Framework (architettura)

Question

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

Sito web

Questo contiene tutto il front-end.

Progetto C# - MLS.Game.Data

Questo contiene il file EDMX con tutte le mie mappature dei dati.Non c'è molto altro qui.

Progetto C# - MLS.Game.Business

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

Dal sito web, farò qualcosa del genere:

var planet = PlanetManager.getPlanet(1);

Restituisce a Pianeta oggetto da MLS.Game.Data (generato da EDMX).Funziona, ma mi dà un certo fastidio perché significa che il mio front-end deve fare riferimento a MLS.Game.Data.Ho sempre pensato che la GUI dovesse fare riferimento solo al progetto Business.

Inoltre, ho scoperto che le mie lezioni per Manager tendono a diventare molto pesanti.Mi ritroverò con dozzine di metodi statici al loro interno.

COSÌ...la mia domanda è: in che modo tutti gli altri presentano i propri progetti ASP EF?

MODIFICARE

Dopo un altro po', però, ci sono altri elementi che mi danno fastidio.Ad esempio, supponiamo che io abbia il mio oggetto Pianeta, che ancora una volta viene generato codice dalla procedura guidata.E se arrivasse il momento in cui il mio Pianeta avesse bisogno di avere una proprietà specializzata, diciamo "Popolazione", che è un calcolo di qualche tipo basato su altre proprietà dell'oggetto Pianeta.Vorrei creare una nuova classe che eredita da Planet e poi restituirla invece?(hmm, mi chiedo se quelle classi sono sigillate dall'EF?)

Grazie

Answer 1

Potresti provare quanto segue per migliorare le cose:

• Utilizza EF per recuperare i DTO nel livello dati, quindi utilizza questi DTO per popolare oggetti business più ricchi nel livello aziendale.Solo allora la tua interfaccia utente dovrà fare riferimento al livello aziendale.
• Una volta creati i ricchi oggetti business, è possibile iniziare a interiorizzare parte della logica delle classi manager, ripulendo in modo efficace il livello aziendale.

Personalmente preferisco il modello più ricco rispetto al modello manager perché, come dici tu, ti ritrovi con un carico di metodi statici, che inevitabilmente finisci per concatenare insieme all'interno di altri metodi statici.Trovo che questo sia troppo disordinato e, cosa ancora più importante, più difficile da comprendere e garantire la coerenza dei tuoi oggetti in un dato momento.

Se incapsulate la logica all'interno della classe stessa potete essere più certi dello stato del vostro oggetto indipendentemente dalla natura del chiamante esterno.

Una bella domanda comunque.

Answer 2

IMHO, il tuo layout attuale va bene.È perfettamente normale che la tua 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 vengono spesso definiti livello "oggetti business" (BOL).Un layout comune sarebbe quindi quello di avere un livello di logica aziendale (BLL) che è il livello "Manager" e un livello di accesso ai dati (DAL).Nel tuo scenario, LINQ to Entites (presumendo che lo utilizzerai) è il tuo DAL.Un modello di riferimento normale sarebbe quindi: -

L'interfaccia utente fa riferimento a BLL e BOL.BLL fa riferimento a BOL e DAL (LINQ to Entites).

Dai un'occhiata a questa serie di articoli per maggiori dettagli.

Answer 3

Per quanto riguarda la tua seconda domanda (dopo EDIT) se hai bisogno o vuoi aggiungere funzionalità ai tuoi oggetti EF puoi utilizzare classi parziali.Fare clic con il pulsante destro del mouse sul file EDMX e selezionare Visualizza codice.

Oppure, se questo non ti basta, puoi abbandonare il designer e scrivere le tue classi abilitate per EF.

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

Answer 4

Per quanto riguarda la tua seconda domanda nella sezione "MODIFICA":

Se non sbaglio, le classi generate da EF non sono sigillate e lo sono PARZIALE classi, in modo da poterle estendere facilmente senza toccare i file generati stessi.

La classe generata sarà:

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

così puoi facilmente creare il tuo "PlanetAddons.cs" (o come vuoi chiamarlo) per estendere questa classe:

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

Abbastanza carino, eh?Non è necessario derivare e creare gerarchie di oggetti artificiali....

Marc

Answer 5

Non sono un esperto, ma mi sembra abbastanza buono.È simile a quello che ho nelle mie soluzioni, tranne per il fatto che unisco semplicemente il progetto EF con il progetto aziendale.Le mie soluzioni non sono così grandi e i miei oggetti non richiedono molta intelligenza, quindi per me va bene.Anch'io ho un sacco di metodi diversi per ciascuna delle mie classi di supporto statico.

Se non vuoi che il livello di presentazione venga a conoscenza del livello di accesso ai dati, allora devi creare alcune classi intermedie, il che probabilmente richiederebbe molto lavoro.Allora qual è il problema con la tua configurazione attuale?

Answer 6

Il tuo layout sembra ok.Avrei aggiunto un livello Utilità/Comune

Interfaccia utente Web
Livello aziendale
Oggetti dati
Livello utilità

Answer 7

Aggiungerei DTO al livello aziendale che sono rappresentazioni di "oggetti stupidi" (ad es.solo proprietà) delle entità nel livello dati.Quindi le tue classi "Manager" possono restituirli, come ad esempio:

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

e la tua interfaccia utente può gestire solo il livello BLL tramite POCO;il Manager (quella che chiamerei una classe "Mapper") gestisce tutta la traduzione tra gli oggetti e il livello dati.Inoltre, se è necessario estendere la classe, è possibile avere una proprietà "virtuale" sull'oggetto DTO e fare in modo che il Manager la traduca nuovamente nei suoi componenti.