Czy CodeFirst jest przeznaczony do zastosowań na dużą skalę?

16

Czytałem o Entity Framework, w szczególności EF 4.1 i podążałem za tym linkiem ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx ) i przewodnik po Code First.

Uważam, że jest fajnie, ale zastanawiałem się, czy Code First ma być tylko rozwiązaniem do szybkiego programowania, w którym możesz po prostu wskoczyć bez większego planowania, czy rzeczywiście jest przeznaczony do zastosowań na dużą skalę?

RoboShop
źródło
Myślę, że podejście oparte na kodzie jest bardziej odpowiednie do kpienia. Jest więc bardziej przyjazny dla testów.
Gulshan
9
Code-first to co najmniej doskonała technologia do pracy z DBA w niekontrolowanej pianie. Dlatego nie może być wszystko źle.
3Sphere,

Odpowiedzi:

17

Być może mam tam niektórych krytyków, ale kiedy przeczytałem niektóre z postów od Hanselmana i Gutherie, a potem przeczytałem książkę Julii Lerman o Entity Framework, miałem naprawdę NAPRAWDĘ trudności z kodem. W ciągu wielu lat budowania aplikacji podążałem wieloma ścieżkami, zarówno wymuszonymi przez proces, jak i z wyboru, i odkryłem, że odnoszę dużo większy sukces, gdy patrzę na dane zorientowane podczas tworzenia aplikacji.

Mówię tutaj o linii aplikacji biznesowych ... to wtedy masz problem biznesowy lub proces, który musi mieć rozwiązanie programowe. Masz dane, które w jakiś sposób wymagają zarządzania. Lepiej poznać swoje dane i sposób, w jaki odnoszą się one do siebie i jak są wykorzystywane w firmie. Dlatego modelujesz te dane, a następnie tworzysz wokół nich aplikację / rozwiązanie. Z mojego doświadczenia wynika, że ​​jeśli zaczniesz tworzyć aplikację z danymi jako refleksją, coś w końcu zostanie pominięte, a następnie będziesz miał pewne refaktoryzowanie (w wielu przypadkach - refaktoryzacja MAJOR).

Małe aplikacje mogą być wyjątkiem, ale nadal będę korzystać z mojego podejścia do danych.

Catchops
źródło
2
Może to wynikać z tego, że to podejście jest dla mnie trochę obce i mogę później zmienić zdanie, ale nawet w przypadku małych aplikacji wydaje mi się, że najpierw bardziej komfortowo byłoby budować z bazy danych. To wydaje się być najbardziej logicznym punktem wyjścia.
RoboShop
5
Nawet jeśli baza danych jest oparta na CodeFirst, nadal używasz podejścia skoncentrowanego na danych. Po prostu modelujesz swoje dane przy użyciu klas .Net zamiast ścisłej bazy danych. Jeśli możesz modelować swoje dane w klasach .net, co i tak musiałbyś zrobić, aby wiedzieć, jak korzystać z danych, to nie widzę, jak to jest główną przeszkodą w umożliwieniu EF utworzenia schematu do obsługi tego modelu danych.
KallDrexx,
1
Chciałbym również dodać, że jeśli nie korzystasz z EF 5.0+ i .NET 4.5+, wybranie Code First spowoduje ograniczenie wydajności twojej aplikacji ze względu na niemożność wygenerowania obiektów CompiledQuery. Obecnie jestem w trakcie przenoszenia aplikacji z CodeFirst do bazy danych, ponieważ utknęliśmy w EF 4.3
Esteban Brenes
Problem biznesowy implikuje procesy biznesowe, które implikują zachowanie. Dane są zwykle efektem ubocznym tego zachowania (chyba że mówisz o prostych aplikacjach CRUD), więc moim zdaniem lepiej skupić się najpierw na zachowaniu modelowania, niż na modelowaniu DB.
Stefan Billiet
5

Nie rozumiem, dlaczego CodeFirst nie może być stosowany w dużych projektach dla przedsiębiorstw. Powiem, że używam EF CodeFirst w kilku projektach, jednym, w którym baza danych jest generowana przez mój model EF CodeFirst, a drugim, w którym EF CodeFirst jest mapowany na istniejącą bazę danych.

Z mojego doświadczenia wynika, że ​​skuteczność CF w dużym projekcie zależy w dużej mierze od stopnia abstrakcji warstwy danych od warstwy biznesowej.

Na przykład w jednym z moich projektów warstwa biznesowa wywołuje bazę danych bezpośrednio przez linq. Używam Linq do abstrakcji mojej warstwy bazy danych i używam CodeFirst do mapowania moich POCO do schematu bazy danych. W tym przypadku CodeFirst znacznie upraszcza utrzymywanie różnic między konwencjami DB (nazwami relacji i tabel) a nazwami moich klas C # i mogę wprowadzać zmiany w bazie danych bez konieczności silnego wpływu na interakcję mojej warstwy biznesowej z bazą danych.

Jednak w innym projekcie abstraktuję dostęp do bazy danych do nietypowego wzorca repozytorium, a metody Get * mojego repozytorium są wyłącznie odpowiedzialne za uruchamianie zapytań w bazie danych i zwracają rzeczywiste obiekty (nie IQueryable<T>s). W tym przypadku metody repozytorium konwertują jednostki DB na jednostki POCO, w tym przypadku CodeFirst nie zapewnia tak dużej korzyści, jak POCO CodeFirst są krótkotrwałe i szybko są przekształcane w klasy C # warstwy biznesowej.

Ostatecznie tak naprawdę zależy to od struktury zespołu i od tego, jak wygodny jest zespół (lub seniorzy) z inżynierami niebędącymi DBA modyfikującymi schematy bazy danych oraz od tego, jak duże zmiany schematu wpłyną na strukturę kodu. Gdy CodeFirst jest odwzorowany na istniejącą bazę danych, nie jest dla mnie łatwe przekształcanie właściwości na nową nazwę kolumny bez konieczności globalnej zmiany nazwy tej właściwości, co jest szczególnie istotne, gdy mówimy o nazwie, która ma większy sens dla pola bazy danych zamiast właściwości C #. Dodanie obsługi kodu dla nowych pól bazy danych jest również dla mnie trywialne bez konieczności całkowitej przebudowy moich jednostek C # (jeden z powodów, dla których pozostawiłem Linq-to-sql w EF CodeFirst z istniejącej bazy danych).

KallDrexx
źródło
4

Code First nie nadaje się do zastosowań na dużą skalę. Realizacja rozwoju aplikacji na dużą skalę jest bardzo duża.

Zazwyczaj cykl życia Twojej aplikacji biznesowej to:

  1. Wersja 1 jest w produkcji
  2. Wersja 2 jest w fazie beta
  3. Wersja 3 jest w fazie rozwoju
  4. Wersja 4 jest w fazie planowania.

Są też inne mosty komunikacyjne między aplikacjami, niektóre zaplanowane zadania, niektóre integracje stron trzecich, usługi sieciowe dla niektórych różnych urządzeń komunikacyjnych, takich jak telefon komórkowy itp

Ostatecznie Code First używa ObjectContext Modelu Entity, starszy EF generujący EDMX i używanie ObjectContext z EntityObject było naprawdę wystarczające do wszystkiego. Możesz łatwo dostosować szablon tekstowy do generowania kodu. Metoda wykrywania zmian jest wolniejsza w przypadku implementacji ObjectContext, ale zamiast generować proxy zespół EF mógł z łatwością poprawić szybkość wykrywania zmian zamiast najpierw wymyślać kod na nowo.

Zautomatyzowana migracja

Automatyczna migracja brzmi dobrze w teorii, ale w praktyce jest niemożliwa po uruchomieniu. Jest dobry tylko do prototypowania, opracowywania szybkich wersji demonstracyjnych.

Migracja kodu w ogóle nie jest odpowiednia w takim systemie. Wersja 1 i wersja 2 najprawdopodobniej komunikują się z tą samą bazą danych. Wersja 3 i wersja 4 są zwykle tymczasowe i mają inną bazę danych.

Najpierw baza danych

Baza danych to praktyczne podejście, łatwe porównywanie, wizualizacja i obsługa skryptów SQL. DBA mogą z łatwością pracować.

Szablony tekstowe

Stworzyliśmy własne szablony tekstowe do wyszukiwania i tworzenia EDMX i ObjectContext z niewielką niestandardową implementacją, która rozwiązuje problemy z wydajnością. Istnieje wiele aplikacji z wieloma wersjami komunikujących się z tą samą bazą danych bez żadnych problemów.

Dla mnie kliknięcie prawym przyciskiem myszy pliku .tt i kliknięcie „Uruchom narzędzie niestandardowe” jest zdecydowanie najszybszym i najłatwiejszym krokiem niż pisanie zajęć, konfigurowanie i tworzenie modelu.

Akash Kava
źródło
Migracje są przeznaczone właśnie dla opisanego scenariusza.
Casey
Wszystkie migracje (i nie muszą być uruchamiane automatycznie) opisują serię zmian w bazie danych, które chcesz wprowadzić w kodzie. Jeśli nie ma konfliktu między starym modelem a nowym (lub wcale nie potrzebujesz zmian w bazie danych), nie ma powodu, dla którego nie można mieć dwóch wersji korzystających z tej samej bazy danych.
Casey
2
@Casey To duży IF, biorąc pod uwagę czas życia aplikacji :)
BVernon
3

Zwykle dla dużych projektów baza danych została już utworzona. Albo dlatego, że jest to starsza baza danych lub utworzona przez kompetentnego dba do wydajności. Jedyną korzyścią z CodeFirst jest to, że nie chcesz używać encji EF, ale zamiast POCO.

Tony_Henrich
źródło
2

Wydaje mi się, że „Code First” jest przeznaczony do używania EF z bardziej „zwinnymi” (nie haruj zbytnio w tym terminie, niekoniecznie mam na myśli metodologię) i aplikacjami typu greenfield, w których nie masz istniejący model danych lub istniejące dane; rodzaj aplikacji, w której można również użyć Django, frameworka PHP lub Railsów, aby postępować zgodnie z wytycznymi tych frameworków, które normalnie obejmują tworzenie modelu danych jako części kodu, zamiast budowania aplikacji wokół tradycyjnego modelu danych Microsoft sposób obsługi rzeczy.

Aby odpowiedzieć na pytanie, powiedziałbym „nie”; jeśli masz już istniejące dane i tworzysz aplikację do ich obsługi, Code First nie ma większego sensu. Jednak i nie użyłem EF w ogóle bardzo dużo, nie mówiąc już o Code First EF, wygląda na to, że jest to luźniej powiązane podejście do kodu, które zawsze jest korzystne. Zakładając, że możesz użyć Code First, a następnie skierować klasę na istniejący model danych (zamiast być zmuszonym do wygenerowania modelu), podejście Code First może nadal pomóc w pisaniu odpowiednio abstrakcyjnego i testowalnego kodu bez zwykłego „cruft” używania Entity Framework (tj. Wygenerowane metaklasy).

Wayne Molina
źródło
Mam działającą aplikację w wersji 400+ i wszystko zostało utworzone przy użyciu metody EF opartej na pierwszym kodzie, mogłem korzystać z abstrakcji, dziedziczenia o wiele łatwiejszego niż inne metody modelowania (najpierw baza danych, najpierw model). da ci kontrolę nad kodem i będzie łatwy w utrzymaniu, a także nie stracisz nic pod względem wydajności i czasu kodowania.
Monah
1

W naprawdę dużych projektach powiedziałbym, że kodowanie nie ma sensu.

W rzeczywistości, gdy projekt staje się naprawdę duży, często masz ścisłą separację obaw. Nie możesz mieć tej samej osoby, która pisze kod C #, zajmuje się projektowaniem bazy danych, pisaniem HTML / CSS i projektowaniem wizualnym w Photoshopie. Zamiast tego projekt bazy danych jest wykonywany przez administratora bazy danych (lub przynajmniej przez dedykowaną osobę, która zna jej pracę).

Ponieważ baza danych jest zaprojektowana przez osobę znającą bazę danych, SQL oraz narzędzia administracyjne i do projektowania baz danych, dziwne byłoby widzieć tę osobę za pomocą Entity Framework.

Co więcej, nie jestem pewien, czy Entity Framework jest wystarczająco silny, aby właściwie zaprojektować bazę danych. Co z indeksami? Ograniczenia? Wyświetlenia?

Arseni Mourzenko
źródło
Cześć, tak właśnie myślałem. Wydaje mi się, że to fajnie, ale tak naprawdę nie widzę żadnej przewagi nad robieniem tego, co robiłem wcześniej, czyli projektowaniem bazy danych w pierwszej kolejności. Chciałem się tylko upewnić, że to nie dlatego, że było coś, czego nie do końca rozumiałem.
RoboShop
Dodaliśmy bibliotekę rozszerzeń do naszego, bardzo dużego projektu, który pozwala nam dodawać adnotacje do indeksów na obiektach z kodem - działa świetnie i jest stosunkowo łatwy do wykonania.
casper
1

Najpierw kod jest wykonalny nawet dla dużych systemów: po prostu zbadaj model po utworzeniu i zmapuj go za pomocą płynnego interfejsu API, aż dojdziesz do modelu db, który ci się podoba.

Kacper
źródło