Utilizzando Entity Framework, progetto non MVC, è necessario un aiuto con la struttura della classe

Question

Utilizzando Entity Framework, progetto non MVC, è necessario un aiuto con la struttura della classe

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

2

Sto lavorando su un progetto non-MVC di grandi dimensioni che utilizza Entity Framework per l'accesso al database. Questo è un nuovo progetto, quindi abbiamo una vasta area per lo sviluppo.

Il problema concettuale che sto incontrando è come modellare il livello appena sopra i Modelli EF.

A livello di database ho una tabella Customer , Order e Item , quindi c'è un modello per ciascuno.

Ora ho bisogno di descrivere ciò che il Cliente può fare . Ad esempio, in definitiva, voglio dire qualcosa del tipo:

 Order newOrder = customerObject.CreateOrder(itemList);

Dove vive il metodo CreateOrder?

Il mio budello mi dice che c'è una sottoclasse del modello Customer che ha i metodi necessari al Cliente. Con un'interfaccia a quella classe in primo piano per mantenere basse le interdipendenze tra i moduli.

Ma sembra troppo facile per essere il modo corretto.

Alcune domande correlate che ho trovato, ma che non sono esattamente applicabili sono:

class-design entity-framework

posta Clinton Pierce 01.09.2015 - 14:26

fonte

2 risposte

Leggi altre domande sui tag class-design entity-framework

Migliore design dell'applicazione - dove posizionare le interfacce Utilizzo di bool / flag per governare il flusso del programma C ++

score 2 · Answer 1

Quello che ho usato ha funzionato abbastanza bene. Repository sostanzialmente utilizzati per ospitare i metodi chiamati. Tutto è stato diviso in:

Contesto: imposta il contesto db usando il sotto, implementa System.Data.Entity.DbContext . Contiene DbSet delle tue entità. Quindi un esempio sarà il seguente:

public DbSet<Customer> Customers { get; set; }

protected override void OnModelCreating(DbModelBuilder modelBuilder) 
{
    Database.SetInitializer<CustomerDatabaseContext>(null);

    modelBuilder.Configurations.Add(new CustomerConfiguration()); 
}

Entità: mappatura letterale dell'oggetto db

public class Customer
{
    public long Id {get; set;}

    public string Name {get; set;}
}

Configurazioni: impostazione della tua entità

public class CustomerConfiguration : EntityTypeConfiguration<Customer>
{
    public CustomerConfiguration()
    {
        this.Property(x => x.Id).HasColumnName("CustomerId");
        this.HasKey(x => x.Id);
        this.Property(x => x.Name);
    }
}

Repository: contiene tutti i metodi, ad es.

public Customer GetById(long identity)
{
    using (var context = CustomerDatabaseContext.Start())
    {
        return context.Customers.FirstOrDefault(x => x.Id == identity);
    }
}

I repository sono inizializzati nel codice e usati per esempio
```
var customer = this.repository.GetById(request.CustomerId);
```

score 1 · Answer 2

Tutti sembrano essere sul treno del deposito. Dato che EF è già un repository, vorrei spingere la logica di business su un livello di servizio. Un servizio non deve necessariamente essere in una nuova libreria (anche se potrebbe), ma fornisce quella logica aggiuntiva in cima alle entità di base. Per illustrare:

public interface IOrderService : IDisposable
{
    Order Create(Customer customer, params Item[] items);
}

public class OrderService : IOrderService
{
    private DbContext context;

    public OrderService(DbContext context)
    {
        Contract.Requires(context != null);

        this.context = context;
    }

    public Order Create(Customer customer, params Item[] items)
    {
        Contract.Requires(customer != null);
        Contract.Requires(items != null);
        Contract.Requires(items.Length > 0);
        Contract.Ensures(Contract.Result<Order>() != null);

        Order order;

        //
        // Business logic building order;
        //

        return order;
    }
}

Quindi l'utilizzo sarebbe simile a:

// -- Existing variables --
var db = /* your EF context */;
var customer = /* your targetted customer */;
var items = /* the items to be added */;
// -- /Existing variables --

// Executing against new service
var orderSvc = new OrderService(db);
var newOrder = orderSvc.Create(customer, items);

Commento

Tutto ciò che fa un modello di repository (sopra un ORM) è astratto dell'API che è già presente. Ora stai duplicando gli sforzi e, molto spesso, perdendo alcune caratteristiche molto interessanti dell'ORM stesso (questo è perché hai scelto l'ORM usando SqlConnection presumo ... ). Certo, potresti cambiare i tuoi mesi / mesi di ORM da ora, ma vale la pena fare lo sforzo iniziale? (Questo è per te da decidere)