Jaka jest teraz najlepsza metoda utrwalania?

Question

Pochodzę z tła Java.

Ale chciałbym mieć wieloplatformowe podejście do tego, co jest uważane za najlepszą praktykę w przypadku istniejących obiektów.

Tak jak ja to widzę, istnieją 3 obozy:

• obóz ORM
• bezpośredni obóz zapytania np JDBC/DAO, iBatis
• obóz LINQ

Czy ludzie nadal zapytań handcode (pomijając ORM)? Dlaczego, biorąc pod uwagę opcje dostępne za pośrednictwem JPA, Django, Rails.

Answer 1

Nie ma jednej najlepszej praktyki dla wytrwałości (chociaż liczba osób krzyczących, że ORM jest najlepszą praktyką, może prowadzić do przekonania, że ​​jest inaczej). Jedyną najlepszą praktyką jest zastosowanie metody najbardziej odpowiedniej dla zespołu i projektu.

Używamy ADO.NET i procedur przechowywanych w celu uzyskania dostępu do danych (chociaż mamy kilku pomocników, którzy bardzo szybko zapisują takie jak generatory otoków klasy SP, IDataRecord dla tłumacza obiektu i niektóre procedury wyższego rzędu zawierające wspólne wzorce i obsługa błędów).

Istnieje kilka powodów, dla których nie będę tutaj wchodził, ale wystarczy powiedzieć, że są to decyzje, które działają dla naszego zespołu i że nasz zespół się z tym zgadza. Które na koniec dnia są ważne.

Answer 2

Aktualnie czytam uporczywe obiekty w .net. W związku z tym nie mogę zaoferować najlepszej praktyki, ale może moje spostrzeżenia mogą przynieść ci jakąś korzyść. Aż do kilku miesięcy temu zawsze używałem handcoded zapytań, złego nawyku z moich dni ASP.classic.

Linq2SQL - Bardzo lekki i łatwy do uzyskania. Uwielbiam mocno wpisane możliwości sprawdzania i fakt, że SQL nie jest uruchamiany od razu. Zamiast tego jest wykonywany, gdy zapytanie jest gotowe (wszystkie zastosowane filtry), dzięki czemu można podzielić dostęp do danych z filtrowania danych. Również Linq2SQL pozwala mi używać obiektów domen, które są oddzielne od obiektów danych, które są generowane dynamicznie. Nie próbowałem Linq2SQL na większym projekcie, ale jak dotąd wydaje się to obiecujące. Oh, obsługuje tylko MS SQL, co jest wstydem.

Entity Framework - Grałem z nim trochę i nie lubiłem tego. Wydaje się, że chce zrobić wszystko dla mnie i nie działa dobrze z procedurami przechowywanymi. EF obsługuje Linq2Entities, która ponownie pozwala na silnie typowane zapytania. Myślę, że jest to ograniczone do MS SQL, ale mogę się mylić.

SubSonic 3.0 (Alpha) - Jest to nowsza wersja SubSonic, która obsługuje Linq. Fajną cechą SubSonic jest to, że bazuje na plikach szablonów (szablony T4, napisane w C#), które można łatwo modyfikować. Dlatego jeśli chcesz, aby wygenerowany automatycznie kod wyglądał inaczej, po prostu go zmień :). Próbowałem do tej pory tylko podglądu, ale dzisiaj spojrzę na Alphę. Zajrzyj tutaj SubSonic 3 Alpha. Obsługuje MS SQL, ale wkrótce będzie obsługiwał Oracle, MySQL itp.

Dotychczas moja konkluzja jest użycie linq2sql aż SubSonic jest gotowy, a następnie przełączyć się, że od SubSonics szablonów pozwala na znacznie więcej dostosowanie.

Answer 3

Istnieje co najmniej jeden: System Prevalence.

O ile wiem, to, co jest dla ciebie optymalne, zależy od twoich okoliczności. Zauważyłem, że w przypadku bardzo prostych systemów używanie zapytań bezpośrednich może być dobrym pomysłem. Również widziałem Hibernacja nie działa dobrze z kompleks Legacy schematów bazy danych, więc przy użyciu ORM może nie zawsze być poprawnym rozwiązaniem. Prewalencja systemowa ma być niewiarygodnie szybka, jeśli masz wystarczająco dużo pamięci, aby zmieścić wszystkie obiekty w pamięci RAM. Nie wiem o LINQ, ale przypuszczam, że ma swoje zastosowanie także.

Tak, jak to często bywa, odpowiedź brzmi: znać różnorodne narzędzia do pracy, dzięki czemu są w stanie wykorzystać ten, który jest najbardziej odpowiedni dla danej sytuacji.

Answer 4

Najlepsza praktyka zależy od Twojej sytuacji.

Jeśli potrzebujesz obiektów bazy danych w strukturach tabel z jakąś znaczącą strukturą (więc jedna kolumna na pole, jeden wiersz na jednostkę itd.) Potrzebujesz jakiejś warstwy tłumaczenia pomiędzy obiektami i bazą danych. Dzielą się one na dwa obozy:

• Jeśli nie ma logiki w bazie danych (tylko przechowywanie) i tabele mapowania obiektów dobrze, to rozwiązanie ORM może zapewnić szybki i niezawodny system trwałości. Systemy Java, takie jak Toplink i Hibernate, to dojrzałe technologie.

• Jeśli jest logiki bazy danych zaangażowane w utrzymywanie się lub schematu bazy danych dryfował z obiektowego modelu znacząco procedury składowane owinięte Data Access Objects (z późniejszymi wzorów, jak chcesz) jest trochę bardziej zaangażowani niż ORM ale bardziej elastyczny.

Jeśli nie potrzebują uporządkowanego przechowywania (i trzeba być naprawdęupewnić się, że nie, a wprowadzenie go do istniejących danych nie jest zabawa), można przechowywać odcinkach wykresy obiektów bezpośrednio w baza danych, omijając wiele złożoności.

Answer 5

Wolę pisać własne SQL, ale stosuję wszystkie moje techniki refaktoryzacji i inne "dobre rzeczy", kiedy to robię.

Mam napisane warstwy dostępu do danych, generatory kodu ORM, warstwy trwałości, zarządzanie transakcjami UnitOfWork i wiele SQL. Zrobiłem to w systemach o różnych kształtach i rozmiarach, w tym w bardzo wydajnych kanałach danych (czterdzieści tysięcy plików zawierających łącznie czterdzieści milionów transakcji dziennie, z których każde zostało załadowane w ciągu dwóch minut od czasu rzeczywistego).

Najważniejszym kryterium jest przeznaczenie, podobnie jak przy jego kontroli. Nigdy nie pozwól, aby narzędzie ORM było przeszkodą w wykonaniu Twojej pracy lub wymówką, aby nie robić tego dobrze. Ostatecznie wszystkie dobre instrukcje SQL są odręczne i ręcznie dostrojone, ale niektóre przyzwoite narzędzia mogą pomóc Ci szybko uzyskać dobry pierwszy szkic.

Traktuję ten problem w taki sam sposób, w jaki robię projekt interfejsu użytkownika. Piszę wszystkie moje interfejsy bezpośrednio w kodzie, ale mogę użyć wizualnego projektanta do prototypowania kilku istotnych elementów, które mam na myśli, a następnie rozdzierać kod, który generuje, aby uruchomić mój własny.

Wykorzystaj narzędzie ORM w dowolnej z jego manifestacji jako sposób na uzyskanie przyzwoitego przykładu - spójrz, jak rozwiązuje wiele problemów, które się pojawiają (generowanie kluczy, asocjacje, nawigacja itp.). Rozerwij jego produkcję, uczyń ją własną, a następnie użyj go ponownie.