Czy pisanie własnej warstwy dostępu do danych / mapowania danych to „dobry” pomysł?

Jesteśmy obecnie w sytuacji, w której mamy wybór pomiędzy użyciem gotowego mapera relacyjno-obiektowego lub stworzeniem własnego

Mamy starszą aplikację (ASP.NET + SQL Server), w której warstwa danych i warstwa biznesowa są niestety połączone. System nie jest szczególnie skomplikowany pod względem dostępu do danych. Odczytuje dane z dużej grupy (35–40) powiązanych ze sobą tabel, manipuluje nimi w pamięci i zapisuje je z powrotem w innych tabelach w formacie podsumowania. Mamy teraz okazję do pewnego refaktoryzacji i szukamy technologii kandydujących do wykorzystania w celu oddzielenia i właściwej struktury naszego dostępu do danych.

Niezależnie od wybranej technologii, chcielibyśmy:

• mają obiekty POCO w naszym Modelu Domeny, które są Ignoranckie
• mieć warstwę abstrakcji, która pozwala nam na testowanie jednostkowe obiektów naszego modelu domeny w stosunku do próbnego źródła danych

Jest oczywiście wiele rzeczy na ten temat, jeśli chodzi o Wzorce i Struktury itp.

Osobiście nalegam na użycie EF w połączeniu z ADO.NET Unit Testable Repository Generator / POCO Entity Generator . Spełnia wszystkie nasze wymagania, może być łatwo zawarty w strukturze Repo / UnitOfWork, a nasza struktura DB jest wystarczająco dojrzała (już przeszła proces refaktoryzacji), dzięki czemu nie będziemy dokonywać codziennych zmian w modelu.

Jednak inni w grupie sugerują projektowanie / tworzenie własnego DAL całkowicie od zera. (Niestandardowe DataMappery, DataContexts, Repozytorium, Interfejsy wszędzie, Nadmiar umiejętności wstrzykiwania zależności do tworzenia konkretnych obiektów, Niestandardowe tłumaczenie zapytań LINQ na podstawowe, Niestandardowe implementacje buforowania, Niestandardowe implementacje FetchPlan ...) lista jest długa i szczerze mówiąc strajkuje ja jako szaleństwo.

Niektóre z omawianych argumentów to: „Cóż, przynajmniej będziemy kontrolować nasz własny kod” lub „Och, użyłem L2S / EF w poprzednim projekcie i to było tylko bóle głowy”. (Chociaż wcześniej korzystałem zarówno z produkcji, jak i zauważyłem, że problemy są nieliczne i dalekie od siebie i są bardzo łatwe do rozwiązania)

Więc czy któryś z twoich doświadczonych deweloperów / architektów ma jakieś słowa mądrości, które mogą pomóc mi oderwać ten produkt od tego, co wydaje mi się, że to będzie całkowita katastrofa. Nie mogę nie myśleć, że jakakolwiek korzyść uzyskana dzięki uniknięciu problemów z EF zostanie utracona równie szybko, jak próba ponownego wynalezienia koła.

Oba argumenty przeciwko istniejącym ORM są niepoprawne:

„Cóż, przynajmniej będziemy kontrolować nasz własny kod”

Dlaczego nie napisać własnego języka? Twój własny framework? Twój własny system operacyjny? Aby mieć pewność, że wszystko kontrolujesz, dobrym pomysłem jest również stworzenie własnego sprzętu.

„Och, użyłem L2S / EF w poprzednim projekcie i to były tylko bóle głowy”

EF jest wystarczająco dojrzały i był z powodzeniem stosowany przez wiele osób. Oznacza to, że osoba, która twierdzi, że EF jest niczym innym jak bólem głowy, prawdopodobnie powinna zacząć uczyć się, jak prawidłowo używać EF.

Więc musisz napisać własną ORM?

Nie sugerowałbym tego. Istnieją już ORM na poziomie profesjonalnym, co oznacza, że ​​musisz pisać własne tylko wtedy, gdy:

• Masz dokładny kontekst, w którym wszystkie istniejące ORMy z jakiegoś powodu nie pasują,
• Jesteś pewien, że koszt utworzenia i używania własnego ORM zamiast uczenia się istniejącego jest znacznie niższy. Obejmuje to koszt przyszłego wsparcia, w tym przez inny zespół programistów, którzy musieliby przeczytać setki stron dokumentacji technicznej, aby zrozumieć, jak pracować z ORM.

Oczywiście nic nie zabrania ci pisać własnego ORM tylko z ciekawości, aby się uczyć. Ale nie powinieneś tego robić w komercyjnym projekcie.

Zobacz także pkt 2–3 mojej odpowiedzi na pytanie „Wymyślenie koła na nowo” i NIE żałowanie. Widać, że różne przyczyny ponownego wynalezienia koła nie mają tutaj zastosowania.

Użyj Entity Framework dla wszystkich zwykłych rzeczy CRUD (80 do 95 procent kodu) i użyj niestandardowego kodu dostępu do danych dla każdego pozostałego kodu, który wymaga optymalizacji. To powinno zaspokoić obawy tych, którzy twierdzą, że nie masz wystarczającej kontroli.

To dobry pomysł, jeśli tylko możesz (przynajmniej w rozsądnym stopniu) mieć pewność, że zaoszczędzisz przynajmniej tyle czasu / wysiłku, pisząc własny kod, ile potrzeba do jego wygenerowania. W zależności od sytuacji może to również wpłynąć na harmonogram i należy to również uwzględnić. Musisz również uwzględnić długoterminowe utrzymanie w równaniu. Jeśli rzucisz własną ORM, musisz ją zachować na zawsze (lub przynajmniej tak długo, jak będziesz jej używać).

Najważniejsze jest to, że może mieć sens, w odpowiednich warunkach. Warunki te obejmują na ogół:

1. Projekt, nad którym pracujesz, jest dość duży, więc koszty są amortyzowane w związku z dużym wykorzystaniem.
2. Wykorzystanie danych jest na tyle niezwykłe, że istniejące biblioteki (i takie) działają dość słabo dla twoich celów.

Ryzykując stwierdzenie tego, co oczywiste, te dwa są ze sobą odwrotnie powiązane - jeśli pracujesz nad naprawdę olbrzymim projektem, to nawet niewielkie oszczędności przy każdym indywidualnym użyciu mogą stanowić sumę wystarczającą do uzasadnienia rozwoju. I odwrotnie, jeśli twoje potrzeby są naprawdę niezwykłe, więc zyskujesz dużo przy każdym użyciu, praca może być uzasadniona nawet przy dość małym projekcie.

Jednak przynajmniej na podstawie twojego opisu tak naprawdę nie ma zastosowania w twoim przypadku. Być może jeden (lub nawet oba) zastosował się do wcześniejszego użycia EF przez twojego współpracownika, a może po prostu uprzedził - nie sądzę, że dostarczyłeś nam wystarczających informacji, aby nawet zgadnąć, które (choć uczciwie, powinienem dodać, że „ zgadnij, ponieważ to dlatego, że nie powiedział ci wystarczająco dużo, by zgadnąć).

Gdybym był odpowiedzialny za tę sytuację, myślę, że kazałbym wam i waszym współpracownikom napisać rodzaj dokumentu przedstawiającego stanowisko - listę mocnych i słabych stron widocznych przy każdym podejściu, wraz z prawdziwymi dowodami na poparcie każdego twierdzenia / roszczenia /cokolwiek. Cały zespół miałby wtedy (tj. Musiałby) krytykować każdy artykuł. Podstawowym punktem ich krytyki byłoby ocenianie każdego punktu w dwóch skalach:

1. stopień, w jakim punkt wydaje się dokładny, dobrze poparty faktami itp., oraz
2. stopień, w jakim wydaje się, że punkt dotyczy danego projektu.

Następnie oceniłbym dokumenty i krytykę, aby podjąć decyzję (choć będąc całkowicie szczerym, może być trudno powiedzieć, ile wykorzystałem do podjęcia decyzji i ile wykorzystałem je do uzasadnienia decyzji Już zrobiłem - wiem, że prawdopodobnie nie powinienem tego przyznać, ale w rzeczywistości jestem też człowiekiem ...)

Edytować:

Gdybym chciał być wyjątkowo nieprzyjemny (lub „edukacyjny” - w tym przypadku trudno odróżnić), kazałbym każdemu z was spróbować oszacować ogólny wysiłek rozwojowy zarówno przy użyciu istniejącego ORM / DAL, jak i rozwijania Twój własny. Choć to tylko przypuszczenie, natychmiast zgaduję, że większość ludzi z wielkimi planami na zrobienie własnych nie zawracałaby sobie głowy wydaniem swoich szacunków - zanim opracowali oszacowanie ogólnego wysiłku, który został nawet zdalnie ukończony (i realistyczne), zdawaliby sobie sprawę, że nie było nawet możliwości, aby zbliżyć się do konkurowania z użyciem istniejącego kodu. Jednocześnie „

Edycja 2: (coś w rodzaju sugestii @ CmdKey): Chociaż nie jest to wyraźnie wspomniane, zakładam, że oszacowanie w sposób dorozumiany obejmie ocenę ryzyka. W szczególności oszacowanie czasu powinno zwykle obejmować liczby w stylu PERT:

1. Najlepsze oszacowanie najszybszego, jakie można było zrobić, gdyby wszystko poszło dobrze.
2. „Normalne” oszacowanie - jak długo oczekiwasz.
3. Najgorsze oszacowanie najdłuższego z możliwych, jakie mogłoby zająć, gdyby wszystko poszło źle.

Oczywiście najlepsze i najgorsze szacunki zwykle nie powinny obejmować rzeczy takich jak bezpośrednia boska interwencja, ale powinny obejmować prawie wszystko.

Zwykle nigdy nie jest dobrym pomysłem odkrywanie koła na nowo, a takie postępowanie jest zwykle oznaką technicznej niewiedzy („nie wiem nic więcej i nie chcę się uczyć”) lub arogancji („X jest głupi, mogę napisz własne narzędzie za dwa tygodnie! ”); Istnieją dojrzałe narzędzia, które potrafią robić rzeczy znacznie lepiej niż to, co przeciętny programista może zhakować razem w ciągu kilku tygodni.

To powiedziawszy jednak, są chwile, w których nie można niezawodnie dopasować starszej aplikacji wokół istniejącego rozwiązania (bez względu na to, jak elastyczna jest) bez mnóstwa pracy; w takim przypadku nie jest to „dobry” pomysł, ale lepszy pomysł niż alternatywy (tj. pozostawienie go takim, jakim jest, lub przepisanie połowy, aby móc korzystać z warstwy innej firmy), więc nie masz wyboru.

Byłem przy projekcie, który odrzucił istniejące narzędzia Java ORM, aby napisać własne, z powodu niektórych „krytycznych” funkcji, których nie było w Hibernacji. Był to błąd o wartości wielu milionów dolarów, a koszty rosną z dnia na dzień. Nadal nie mają pełnego wsparcia dla relacji między obiektami. Oprócz całego czasu spędzonego na tworzeniu i utrzymywaniu frameworka spędzają godziny na pisaniu kodu, który można by napisać w kilka minut przy użyciu Hibernacji, lub w wielu przypadkach nie trzeba go wcale pisać.

Istniejące ramy są efektem dziesiątek lat pracy. Absurdalnie naiwne jest wyobrażanie sobie, że jeden zespół może zbliżyć się gdziekolwiek blisko za kilka tygodni roboczych.

Kod, który musisz napisać, to kod, który musisz zachować. Czas spędzony utrzymanie kodu ORM jest czas spędzony nie utrzymywanie aplikacji. O ile ORM nie zapewni ci jakiejś strategicznej przewagi, to nie jest to coś, co wygeneruje pieniądze dla firmy, więc jest to czysty koszt ogólny. Czy Twoja firma wolałaby wydawać pieniądze na koszty ogólne lub ulepszać produkt przynoszący pieniądze? Jeśli dotyczy to wewnętrznej aplikacji, może to nie być problemem, ale wciąż zwiększasz ilość kodu, który trzeba będzie napisać, przetestować i udokumentować.

Powiedziałbym, że wprowadzenie własnego ORM jest ZŁYM pomysłem - chyba że masz bardzo, bardzo bogaty powód, aby to zrobić (przy okazji. Te, które zacytowałeś, nie są wystarczająco dobre :)

Popełniłem błąd, gdy inni przekonali mnie, żebym nie używał ORM, i mogę Wam powiedzieć, że samodzielne napisanie całego DAL naprawdę nas spowolniło i zamiast wdrożyć funkcje, które miały znaczenie dla biznesu, spędzaliśmy czas na DAL (jest to o wiele więcej pracy niż to wygląda).

Nowy EF wydaje się być całkiem dobry, ale jeśli chcesz mieć większą kontrolę - zajrzałbym do mikro ORM / s takich jak: Drapper http://code.google.com/p/dapper-dot-net/ lub PetaPOCO http : //www.toptensoftware.com/petapoco/

Możesz także mieszać i dopasowywać - użyj EF do masowego przechowywania rzeczy, a Drapper do dokładnego dostrojenia.

W każdym razie to tylko moje 2c;)