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

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ę?

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.

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).

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.

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.

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).

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?

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.