Czy to głupie, że nie używam NHibernate do mojego projektu?

Question

Pracuję nad aplikacją sieci web .NET, która korzysta z bazy danych SQL Server z około 20 do 30 tabelami. Większość tabel zostanie uwzględniona w rozwiązaniu .NET jako klasa. Napisałem własną warstwę dostępu do danych, aby odczytać obiekty i zapisać je w bazie danych. Całość składa się z zaledwie kilku klas i bardzo niewiele wierszy kodu en używa generycznych i refleksyjnych, aby dowiedzieć się, jakie SQL i parametry użyć. Teraz można coś takiego zrobić za pomocą NHibernate (lub frameworka similair), a niektórzy współpracownicy twierdzą, że to głupie, że nie używam tego. Moim głównym argumentem za niestosowaniem tego jest to, że chcę maksymalnej kontroli nad moją aplikacją, dokładnie wiem, co robi i jak wszystko działa, nawet jeśli to kosztuje więcej czasu na rozwój. Nie podoba mi się także to, że muszę mapować moją bazę danych w plikach XML (moje własne rozwiązanie pozwala mi mapować je w plikach klasy encji).

Więc, chciałbym usłyszeć od ciebie, czy to naprawdę głupie, aby nie używać NHibernate w tej sytuacji? Czy naprawdę jestem ignorantem, czy też nie jest to taki dziwny pomysł, aby użyć mojego własnego rozwiązania?

Answer 1

Myślę, że w dzisiejszych czasach naprawdę nie ma powodu, aby rozwijać własne ramy wytrwałości, ponieważ istnieje tak wiele dobrych wyborów. Nie musisz używać NHibernate (choć jest to dobry wybór), ale poważnie rozważę użycie czegoś, co jest dobrze przetestowane i ugruntowane w branży, ponieważ będzie miało tendencję do lepszej wydajności i mniej błędów, niż coś, co sam napiszesz.

Answer 2

Prawdopodobnie jest głupio pisać własne klasy zamiast używać NHibernate, ale to mniej głupi do dalszego korzystania z własnych klas, biorąc pod uwagę, że już je napisane. Może.

Answer 3

Ludzie zwykle używają frameworków, które są już napisane, ponieważ, no cóż, są już napisane (i przetestowane).

Ale to jest zaleta do toczyć własne. Tylko Ty i Twoi współpracownicy możecie przyjąć założenia dotyczące swojej domeny. Ogólne ramy, takie jak NHibernate, nie mogą przyjmować wielu założeń, ponieważ nie sprawiają, że jest to bardzo uniwersalne.

Po uruchomieniu własnych, możesz upiec te założenia w swojej strukturze, aby ulepszyć naturalny interfejs API. To powiedziawszy, gdybyś zaczął od początku, zasugerowałbym przyjęcie istniejącego szkieletu i zawijanie go, aby lepiej odpowiadał twoim potrzebom. Ale skoro już coś masz i to działa dla ciebie, nie jestem pewien, czy zaproponowałbym zamianę go na coś innego.

Answer 4

Masz kilka możliwości, które są prawdopodobnie lepsze niż wymyślanie koła. Pozwól mi wymienić dwa najbardziej prawdopodobne możliwości:

1. Używaj Entity Framework dla DAL + DAO. To sprawi, że twoje zajęcia (które już napisałeś) staną się przestarzałe, ponieważ EF stworzy własne i będziesz na bieżąco z najnowszymi możliwościami i technologiami językowymi.

2. Użyj Fluent NHibernate, więc nie musisz pracować z odwzorowaniami XML. W ten sposób zachowasz klasy obiektów biznesowych, które napisałeś i unikniesz żmudnych plików XML NHibernation. To wszystko C#.

Twój sposób myślenia jest dobry. Chcesz kontroli. W porządku.Ale używanie własnego DAL jest obecnie trochę głupie, ponieważ w zasadzie wymyślasz na nowo koło, a ty nie masz przetestowanego/błędnego kodu, który zajmie dużo czasu, aby rozwinąć + test + debugowanie.

Gdybym był tobą, pójdę z opcją # 2, ponieważ robiłem opcję nr 1 i wiem, że musiał dostosować wiele rzeczy, aby prace EF, jak powinien. EF będzie gotowy z V2.

Answer 5

Nie będę cię nazywał głupcem, ponieważ zrobiłem dokładnie to samo w przeszłości. Potem zacząłem używać NHibernate i zastanawiałem się, dlaczego, do diabła, przeturlałem się. To dobrze, dajcie sobie spokój.

Answer 6

Myślę, że jest to kwestia równowagi kontroli. Mówisz, że chcesz kontrolować i nie chcesz mapowań. Jeśli kontrola ta odbywa się kosztem zwiększonego kosztu rozwoju i konserwacji, a tworzenie kodu działa dłużej, to jest problem.

ja osobiście nie widzę problemu w toczenia ramy tak długo, jak to upraszcza powtarzalne zadania i sprawia, że ​​rozwój bardziej wydajne i bardziej stabilny kod z powodu mniej miejsca na interpretację. Udało nam się wdrożyć własne ramy, w tym wdrożenie trwałości/dostępu do danych. Nasze powody, by to zrobić, były jednak specyficzne. W tym przypadku miało to działać w środowisku DDD, które było znacznie bliższe temu, co opisuje Evans, niż to, co zapewniały produkty najbardziej niedostępne na półce.

myślę, że różnica jest jednak, że zrozumieliśmy, że nie było z góry koszt i że ostatecznie zrównoważyć się poprzez oszczędności w czasie rozwoju w przyszłości. Oczywiście, jeśli piszesz kod, który ręcznie musisz zarządzać połączeniami, mapami itp., Prawdopodobnie zejdziesz na złą ścieżkę. Przynajmniej możesz użyć czegoś takiego jak Biblioteka korporacyjna, aby pomóc w zarządzaniu nudą łączności i budową komend. Ale uważam też, że jeśli nie masz możliwości ponownego użycia - nic, co jest typem "ramowym", który można streścić i zastosować do innych projektów, wtedy tworzysz koszmar utrzymania i pochłaniacz czasu, że będziesz jedynym właścicielem z.

Answer 7

Istnieje wiele narzędzi dobry Trwałość, które obecnie nie są dobrze przetestowane i okazały wydajności (NHibernate, LINQ do podmiotów, LLBL Gen Pro). Jeśli twoje potrzeby bardzo się różnią od normalnych struktur przetrwania, to wtedy robiłbym swoje własne. Chciałbym jednak skorzystać z testów i optymalizacji istniejącego narzędzia, jeśli to w ogóle możliwe.

Mając to na uwadze, mogę również przetoczyć swoje własne, jeśli chcę mieć doświadczenie w budowaniu własnego narzędzia ORM i byłem skłonny żyć z wadami (nie tak dobrze przetestowane lub zoptymalizowane jako narzędzia, które istnieją od lat , prędkość na rynek).

Answer 8

Tworzenie własnego rozwiązania, zwłaszcza gdy wydaje się działać dobrze i być tak proste, jak mówisz, nie jest ani nieświadome, ani dziwne. Istnieje wiele sytuacji, w których lepiej to zrobić, niż dodać zależność od oddzielnego projektu, takiego jak nHibernate.

To powiedziawszy, istnieje oczywiście wiele sytuacji, w których kompletne przeciwieństwo jest prawdziwe. :)

To naprawdę zależy od twojego projektu i zespołu. Jeśli tworzysz aplikację dla przedsiębiorstw, która ostatecznie będzie wspierana przez kogoś innego, przestrzeganie standardów branżowych może być dobrym pomysłem, nawet jeśli oznacza to trochę więcej pracy z góry.

Answer 9

Wszystkie odpowiedzi tutaj są świetne, ale jestem naprawdę zaskoczony, że nikt nie wspomniał o Castle ActiveRecord, brzmi bardzo podobnie do tego, co robi twój framework i naprawdę upraszcza interfejs do NHibernate. To jeden ze wzorców, które sprawiły, że Ruby on Rails stała się tak popularna!

Ayende Rahien (jeden z głównych twórców NH) dał wielką prezentację na ActiveRecord w Oredev kilka lat temu, który gorąco polecam: http://www.viddler.com/explore/oredev/videos/89

Answer 10

Byliśmy również za pomocą naszych własnych klas warstwy dostępu do danych i podmiot. Mieliśmy także generator kodu, który generował dla nas wszystkie te klasy. Ale teraz używamy Entity Framework, a my jesteśmy bardziej niż szczęśliwi.

Prosta porada: rozpocznij naukę nHibernate lub cokolwiek innego i zacznij używać go w następnym projekcie.

Answer 11

To zależy od tego, co rozumieją przez "głupi".

Jeśli przez "głupstwo" rozumie się, że nie powinieneś pisać swojej warstwy uporczywości, to prawdopodobnie mają rację, ale to płacze nad rozlanym mlekiem.

Jeśli przez "głupi" rozumieją, że powinieneś przepisać cały istniejący kod, aby użyć innego frameworka (takiego jak NHibernate), kiedy to już działa z twoją, prawdopodobnie są one błędne (chociaż jest coś do powiedzenia na temat # błędów w NHibernate vs prawdopodobne # błędów w twoim).

Jeśli przez "głupstwo" rozumie się, że cały zespół zna NHibernate na zimno, a jest już używany w pozostałej części kodu, więc korzystając z frameworka, utrudnisz pracę zespołowi, mają absolutną rację, i prawdopodobnie powinieneś możliwie jak najszybciej zmodyfikować kod w NHibernate, zanim jakikolwiek inny kod zostanie zablokowany w twojej strukturze.

Jeśli przez "głupi" rozumieją, że nikt tak naprawdę nie zna NHibernate, po prostu to lubią, to ... nikt nie wygrywa. Są wybredni, zaimplementowałeś ramy, których nie musiałeś ... nazwijmy to krawatem.

Wszystko to powiedziane, każdy powinien napisać szkielet trwałości lub trzy. Ci prawdopodobnie nie powinni skończyć w czymkolwiek, co statki, ale to dobre ćwiczenie. Jedynym błędem, który popełniłeś, było związanie kodu, który zespół musiał utrzymywać w dobrym ćwiczeniu.

Answer 12

Entity Spaces - http://www.entityspaces.net/Portal/Default.aspx

jest również dobrym narzędziem.

Answer 13

Skończyło się na użyciu Fluent NHibernate do pracy. Wszystkie moje klasy encji zostały wygenerowane przy pomocy ActiveRecordGenerator (http://code.google.com/p/active-record-gen/)