Połączenie Entity Framework, Dapper i SSDT?

Question

Jestem na wczesnym etapie tworzenia nowego projektu rozwojowego i nie jestem pewien, jak skonfigurować strategię dostępu do bazy danych. Będę korzystał z Visual Studio 2012 i będę kierować reklamy na platformę .NET 4.5 i SQL Server 2008 lub 2012.

Nie jestem pewien, czy używać Entity Framework, a jeśli tak, to w jakim stopniu. Ponieważ czytanie danych z bazy danych, a następnie przetwarzanie będzie głównym zadaniem tej aplikacji, ważna będzie wydajność zapytań. Wiem, że EF5 jest o wiele lepszy niż EF4.x w tym zakresie, ale nie martwię się o nieodłączne obciążenie EF (chociaż coś takiego jak Dapper jest nadal co najmniej dwa razy szybsze), ale bardziej lenistwo, jakie ci ono daje jako programista, ponieważ zapytanie za dużo jest tak łatwe dzięki LINQ. Dlatego chcę, aby czystsze zapytania SQL były głównym sposobem pobierania danych.

Jednak to, co ja najbardziej brakuje EF jest:

1. kompilacji sprawdzanie zapytań czas.
2. Śledzenie zmian.
3. Kod pierwszy rozwój.
4. Wzór jednostki pracy.

mogę żyć bez śledzenie zmian, nie jest zazwyczaj trudne do określenia, co jest nowe lub zaktualizowane.

Chcemy, aby twórcy tego projektu nie musieli bawić się projektantami tabel, ale mogli po prostu pisać POCO. Dlatego naprawdę doceniam pierwsze podejście Kodeksu EF. Dzięki temu programista może sklonować kod źródłowy, zadzwonić pod numer update-database i mieć działającą lokalną bazę danych. To coś, co w przeszłości dobrze się sprawdziło.

Inną rzeczą, która jest dla mnie bardzo ważna, jest wzorzec pracy, czyli atomowość wkładek i aktualizacji. Chcę umieścić w kolejce wszystkie zmiany i mieć jeden punkt, w którym zadzwonię pod numer SaveChanges. W przypadku bibliotek takich jak DapperExtensions otrzymasz metodę Insert, ale natychmiast wykona połączenie z bazą danych. Możesz uczynić ją atomową, zawijając transakcję wokół niej, ale to nie to samo, co w kolejce. Musiałbym więc osobiście wdrożyć jakiś mechanizm kolejkowania.

Do sprawdzania kwerend czasu kompilacji rozważam użycie narzędzi SQL Server Data Tools (SSDT). Zapytania będą procedurami przechowywanymi (aby uniknąć dużych bloków ciągów zapytania w kodzie C#) i przy użyciu SSDT można je sprawdzić w czasie kompilacji. Kolejną zaletą SSDT jest możliwość wdrożenia procedur przechowywanych z Visual Studio do docelowej bazy danych. A co najważniejsze, skrypty SQL dla nich będą podlegać kontroli źródła.

Więc z tym, moje rozwiązaniem byłoby w zasadzie składa się z trzech technologii dostępu danych:

Entity Framework

• będzie odpowiedzialny za tworzenie bazy danych z datamodels poco.
• Służy do wstawiania/aktualizacji danych za pomocą wzoru jednostki pracy. Jednym z zastrzeżeń jest to, że najpierw musisz uzyskać Attach encje, które pobrano przez SQL do kontekstu.

SSDT

• byłyby wykorzystywane do sprawdzenia skryptów SQL w czasie kompilacji.
• Pozwala skryptom żyć w Git.
• Wdrożenie rzeczy, których EF nie może wdrożyć w bazie danych.

Wytworny/inny Micro ORM

• byłyby wykorzystywane do pobierania danych

nie mogę pomóc, ale czuję, że jest to nieco roztworu Frankensteina, gdzie korzystanie z różnych bity i kawałki wszystkiego. Nie jestem też pewien, że SSDT i EF będą ze sobą dobrze współpracować. Ten szybki przykład wygląda na to, że działa dobrze:

// Combo of Dapper, EF and a stored proc that was published through SSDT 
static void Main(string[] args) 
{ 
    var connectionString = ConfigurationManager 
    .ConnectionStrings["DbDataContext"].ConnectionString; 

    using (var conn = new SqlConnection(connectionString)) 
    using (var ctx = new DbDataContext()) 
    { 
    conn.Open(); 

    var product = conn.Query<Product>("GetProduct", 
     commandType: CommandType.StoredProcedure).First(); 

    ctx.Products.Attach(product); 

    var order = new Order 
    { 
     Product = product 
    }; 

    ctx.Orders.Add(order); 

    ctx.SaveChanges(); 

    } 
} 

To podejście wydaje się działać, ale jest też niechlujne. Ale jeśli zrezygnuję z SSDT, stracę kontrolę nad kompilacją SQL, jeśli zrezygnuję z Entity Framework, przeoczę się na pierwszym i łatwiejszym wstawianiu, a jeśli zrezygnuję z prostego kodu SQL, będę tęsknił na dużej części wydajności.

Czy istnieje alternatywa, z której nie korzystam? Jeśli nie, jakie jest najlepsze podejście?

Answer 1

Powinieneś naprawdę sprawdzić ServiceStack.Orm.

https://github.com/ServiceStack/ServiceStack.OrmLite

To ma mnóstwo funkcji, w tym modelu gen użyciu plików tt, i może tworzyć tabele db również.

Obsługuje LINQ.

I jego szalony błyskawiczny post.