Entity Framework senza accesso diretto alla tabella

Question

Entity Framework senza accesso diretto alla tabella

#1 da (5 voti)
#2 da (-1 voti)

4

Ci sono alcune domande simili che ho trovato qui, ma nessuna risponde esaurientemente alla domanda che sto ponendo. Domande simili: qui e here

Nella mia azienda, sviluppo applicazioni C # .NET e i nostri Server Admin in ambito IT non consentono l'accesso diretto alla tabella, pertanto è necessario utilizzare stored procedure per l'inserimento, l'aggiornamento e l'eliminazione da una tabella. In passato ho utilizzato DataSet e TableAdapters per accedere alle tabelle di un database, ma sto iniziando a rendermi conto che tutto sta iniziando a utilizzare Entity Framework.

Qui sta il mio problema. C'è un altro sviluppatore qui che usa Entity Framework, ma in realtà non usa le entità. Usa i modelli di entità che non hanno tabelle o viste, solo stored procedure. Questo non sconfigge lo scopo del Entity Framework, o sono pazzo?

Inoltre, mi rendo conto che è possibile mappare l'inserimento, l'aggiornamento e l'eliminazione delle funzionalità nelle stored procedure e questo l'articolo menziona alcuni modi interessanti per implementarlo, ma creare visualizzazioni per ogni tabella sarebbe un grave problema. Esistono alternative più pratiche o facilmente implementabili?

c# sql sql-server entity-framework

posta austincrft 12.08.2014 - 15:41

fonte

2 risposte

-1

Penso che tu sia sulla strada giusta con il supporto delle procedure memorizzate EF. Non sarei d'accordo con il tuo pov in merito alla difficoltà di creare proc e viste memorizzati.

Visualizzazioni: Una vista per tabella

Procedure memorizzate: Avrai bisogno di almeno tre stored procedure

Create
Update
Delete

E la maggior parte è il codice della piastra della caldaia.

Se il database è troppo grande prova a utilizzare un qualche tipo di strumento generatore di codice. O è molto semplice avere un modello per le stored procedure nel progetto SSDT di Visual Studio.

Una volta che hai sopra le quattro cose in atto considerando di utilizzare una sorta di modello di repository generico, sarebbe facile scrivere il codice del tuo Business Services.

public class MyBusinessService : IMyBusinessService
{
    public void InsertData(DataDTO dto)
    {
         ...
         _repo.Add(data);
         _repo.SaveChanges();
    }
}

Se ci pensi, la quantità di tempo che passi a scrivere stored procedure personalizzate per ciascuna operazione, è grande rispetto a una su tre stored procedure e una vista. Inoltre, tutti i codici di servizio possono essere testabili.

La cosa che devi considerare quando usi EF (ed è vera per qualsiasi ORM) è che genera SQL per te dal tuo codice C #, quindi devi prestare attenzione a come scrivi la tua EF alle query di Linq.

risposta data 13.08.2014 - 11:54

fonte

Leggi altre domande sui tag c# sql sql-server entity-framework

Interfaccia per enumerare su file Utilizzo - Factory Pattern vs Injection dipendenza [chiuso]

score 5 · Accepted Answer

Dipende dal tuo background e dalle tue preferenze.

Alcune persone hanno iniziato a utilizzare stored procedure e sono molto a loro agio con loro. Amano T-SQL e possono fare molto con esso. Tendono a scrivere prima gli SP e poi usano un wrapper minimale per usare l'SP. Nota che alcune persone preferiscono i propri SP molto della logica come convalida, regole aziendali, trasformazioni di dati, ecc.

Altre persone sono più a proprio agio con la programmazione orientata agli oggetti e preferiscono scrivere classi e quindi serializzare quelle classi da e verso un database. In questi casi la logica tende ad essere nelle classi.

Il framework Entity supporta entrambi i tipi di sviluppo. È principalmente agnostico di stile di sviluppo e non eccessivamente supponente.

Ma nella tua situazione tu e il tuo team avete bisogno di escogitare qual è lo standard. È necessario prendere una decisione su quante funzionalità EF si intende utilizzare e lo stile di sviluppo del database.

Personalmente mi propongo di utilizzare tutto ciò che l'EF può fornire, quindi lascio che generi tutte le entità. Quindi uso Linq to Objects per spostare i dati da e verso le entità e lasciare che EF gestisca l'I / O del database. Trovo che farlo mi consenta di creare un bel codice ristretto che sia riutilizzabile e verificabile e, cosa più importante, comprensibile.