Come devo progettare un'applicazione di architettura a 3 livelli con Entity Framework?

Question

Come devo progettare un'applicazione di architettura a 3 livelli con Entity Framework?

#1 da (2 voti)

2

Questo mi sta facendo impazzire. EF ci offre un'esperienza di grande convenienza nello sviluppo.

Tuttavia, se abbiamo bisogno di usare il modello Entity nel livello superiore, inseriamo sempre un riferimento dal livello superiore a DAL o qualche livello in basso che detiene la classe Entity. Ho visualizzato la situazione.

                                     +-------------------+
                                     |                   |
                                     |   Presentation    |
    (This layer is directly referring to DAL, which break the 3-tier architecture rules)
                                     +-------------------+
                                               |
                                               |
                                               |
                                               |
                                     +---------v---------+
                                     |                   |
                                     |        BLL        |
                            (Function that returning Entity Model)
                                     +-------------------+
                                               |
                                               |
                                               |
                                               |
                                     +---------v---------+
                                     |                   |
                                     |        DAL        |
                                     (Repo & Entity Model)
                                     +-------------------+

Implementare qualcosa come DTO su BLL è piuttosto pesante e non può risolvere completamente questo problema. Quindi non posso provare ad implementare DTO su tale livello.

Nel frattempo, ho scoperto che alcuni progetti potrebbero eliminare quei Entity Model come il seguente diagramma. È un buon modo per risolvere il problema?

                             +-------------------+
                             |                   |
          +------------------+   Presentation    |
          |                  |                   |
          |                  +---------+---------+
          |                            |
          |                            |
          |                            |
          |                            |
    +-----v------+           +---------v---------+
    |            |           |                   |
    |  Entities  <-----------+        BLL        |
    |            |  (Function that returning Entity Model)
    +-----^------+           +---------+---------+
          |                            |
          |                            |
          |                            |
          |                            |
          |                  +---------v---------+
          |                  |                   |
          +------------------+        DAL        |
                             |   (Repositories)  |
                             +-------------------+

Sebbene questo progetto possa risolvere parte del problema, gli sviluppatori possono tentare di aggiornare l'entità al DB da Presentation Layer chiamando entity.SaveChanges() . Che è così pericoloso Come posso impedire ad altri sviluppatori di chiamare SaveChanges() al livello superiore?

c# design-patterns entity-framework orm n-tier

posta mannok 25.10.2018 - 06:24

fonte

1 risposta

Leggi altre domande sui tag c# design-patterns entity-framework orm n-tier

Concetti di importanza globale da comprendere? [chiuso] Le sessioni sono sicure per captcha al login fallito?

score 2 · Answer 1

How can I prevent other developer from calling saveChanges() at the upper layer?

L'unico modo sensato per farlo è quello di forzare una vera separazione tra i livelli, e l'unico modo ragionevole che puoi fare è di mantenere il tuo set di oggetti Data Transfer (DTO) all'interfaccia Presentation / BLL, che sconfigge lo scopo di utilizzare Entity Framework.

Lascia che ti mostri qualcosa.

Al mio precedente lavoro, abbiamo utilizzato Entity Framework, ma non abbiamo mai chiamato SaveChanges() o utilizzato l'oggetto DBContext per qualsiasi cosa tranne che fa riferimento alle classi Entity. Invece, abbiamo usato le query nude.

using (var context = new CustomerContext())
{
    var customer = context.Database.SqlQuery<Customer>(
          "SELECT * FROM Customers WHERE CustomerID = {0}", customerID).FirstOrDefault();
}

Nel tempo, abbiamo iniziato a rinunciare all'uso dei DTO generati da EF e abbiamo appena iniziato a creare i nostri DTO. Le query bare non richiedono tutti i macchinari che EF inserisce in un DTO, come il rilevamento delle modifiche, e puoi personalizzare ciascun DTO per query specifiche.

Sembra che stessimo affrontando un sacco di lavoro che Entity Framework già fa per te, ma ha alcuni vantaggi significativi:

Le query del database sono indirizzate in modo specifico a ciascuna attività.
Molto più semplice sotto il cofano.
Prestazioni sostanzialmente migliori.

Nel mio attuale lavoro, ho portato avanti questa tecnica, ma ho sostituito Entity Framework con Dapper, il micro-ORM utilizzato da Stack Exchange. Le query sembrano quasi esattamente come sopra. Io uso questo strumento per generare classi di entità.

La cosa bella di Dapper è che contiene estensioni CRUD che includono il rilevamento delle modifiche. Chiama solo Update() sulle entità interessate. La differenza è che ora puoi nascondere il metodo di aggiornamento dal tuo livello di presentazione, se lo desideri; basta rinunciare all'oggetto IDbConnection utilizzato da Dapper.