Istnieje wiele sposobów łączenia się i interakcji z warstwą bazy danych. Na przykład w języku Java najczęściej używane są wywołania surowego kodu SQL, obiektowo odwzorowujące odwzorowania, JDBCTemplate (Spring), procedury składowane itp.Jaki jest twój ulubiony sposób interakcji z bazami danych z Twojego języka programowania?
W swoim języku, która opcja jest twoją preferencją i dlaczego? Kiedy rozważasz pozostałe?
ORM za każdym razem, najmniej muszę myśleć o bazach danych, tym lepiej.
Preferuję zbudować warstwę modelu obiektu biznesowego (obiekty i kolekcje obiektów).
Buduję możliwość interakcji z bazą danych w każdym obiekcie/kolekcji (w przypadku serwera SQL używam System.Data.SqlClient). Użyłem tego wzorca dla SQL Server, MySQL i Oracle.
Następnie wchodzę w interakcje z obiektami z mojego kodu aplikacji.
Dzięki abstrakcji mojej bazy danych w obiektach mój kod aplikacji jest spójny niezależnie od bazy danych zaplecza.
LINQ jest droga dla mnie stąd na
bardzo podoba mi się tier sposób robienia rzeczy 3 + 1. Jedna warstwa dla interfejsu użytkownika, jedna dla logiki biznesowej i dla danych trwałych. Ostatni, który mówisz? Obiekty domen i interfejsy. Umożliwia to załadowanie jednego lub dwóch głównych poziomów wraz z "warstwą" domeny, a kod powinien działać.
To opiera się głównie na zasadach dependency injection i Inversion of Control. Warstwa danych/trwałości ma tylko dwie rzeczy. Tworzy, odczytuje, aktualizuje i usuwa dane oraz odwzorowuje je na format obiektu domeny.
Warstwa interfejsu użytkownika działa dokładnie odwrotnie. Wyświetla i odbiera dane w sposób, do którego użytkownik może się odnosić i mapuje dane wyjściowe/wejściowe do formatu obiektu domeny.
Poziom logiki biznesowej wystarczy znać jedną rzecz. Logika biznesowa. Nie dba o to, skąd pochodzą dane i nie dba o to, gdzie umieszcza go warstwa danych. Wie, że powinien oznaczać konto, które zostało po prostu przekroczone, jak fizycznie zrobić, to nie jest częścią jego pracy.
Obiekty domeny same w sobie nie mają żadnej logiki, są tylko kontenerami do przekazywania danych między poziomami. Oznacza to, że możesz ładować obiekty domeny i interfejsy bez konieczności myślenia o zależnościach.
Pod koniec dnia czuję, że mam dość wyraźną podstawę kodu z wyraźnie oddzielonymi poziomami. A z pewnymi ścisłymi interfejsami i dobrymi klasami bazowymi większość kodowania mówi programowi, co ma zrobić, gdy X się wydarzy. Jak to powinno wyglądać.
</rant>
Edytuj: O, tak. Dotyczy to zarówno LINQ, SubSonic i innych ORM.
ORM jest rzeczywiście fantastyczny.
Używam SQL Alchemy podczas pracy w Pythonie - działa z niemal każdym systemem DBMS, w którym działam.
Do lekkich aplikacji opartych na danych na MacOS X używam Core Data, która ma świetne narzędzie do modelowania danych dostępne przez Xcode.
Obie te wartości pokazują, że ORM wykonane poprawnie jest doskonałe. Miałem mniej sukcesów i radości z EJB.
Jeszcze nie dostałem się do świata LINQ, ale naprawdę pokochałem klasy DataTable/TableAdapter, które Visual Studio wykonał za pomocą zbioru danych XSD. Za pomocą kilku przeciągnięć i kliknięć po utworzeniu schematu bazy danych, mam teraz obiekt DataSet/DataTable, który jest silnie wpisany i mam metody adapterów, które używają sparametryzowanych zapytań do moich procedur przechowywanych dla wszystkich moich instrukcji CRUD. Stworzy to nawet adaptery tabel zapytań dla niektórych z tych procedur, które nie są bezpośrednio powiązane z tabelą.
Aha, a jeśli jeszcze nie utworzono procedur przechowywanych i po prostu mają tabele, kreator utworzy procedury lub instrukcje SQL adhoc dla ciebie.
Ta aplikacja została opublikowana w Visual Studio 2005 i drastycznie ograniczyła czas mojej "struktury" dzięki nowym aplikacjom internetowym i mogę bardziej skupić się na logice biznesowej i prezentacji.
W C# Kocham LINQ to SQL za nic nowego, ale bardzo lubię używać .netTiers + CodeSmith Generator, aby uzyskać szybką i brudną warstwę danych do bazy danych, jeśli używam C# na .NET 2.0.
Ruby on Rails "ActiveRecord ociera podłogę ze wszystkim, co do tej pory widziałem. LINQ wygląda na to, że może być lepiej w niektórych przypadkach, ale ActiveRecord jest tak elastyczny.
Lubię Hibernate dużo :)
wiem, że ma krzywej uczenia się, ale po opanowaniu go, jest dość miłe.
trzeba dodawać, że nie mogę się doczekać, aby dostać w swoje ręce nowego Entity Framework w .NET 3.5 SP1 (wiem, że jest już dostępny, ale jestem trochę leniwy, aby typu XML :))
ActiveRecord , który jest wzorem udokumentowanym najpierw (jak sądzę) w Fowler's Patterns of Enterprise Architecture. Uważam, że jest on implementowany w językach innych niż Ruby, chociaż jest dobrze znany jako podstawowa technologia w Railsach. Niezależnie od tego, jest to zgrabna abstrakcja bazy danych, chociaż muszę przyznać, że uważam ją za nieco nieostrożną iw obszarze find_by_sql. Ale to może być po prostu ja.
Ale (zakładając teraz kapelusz Grumpy Old Man) wszystkie ORMy na świecie nie są substytutem dobrej znajomości SQL, bez którego naprawdę nie lubię dostępu do RDBMS, który jest w ogóle dozwolony.
Obecnie korzystamy z ODAC, aby rozmawiać z bazą danych Oracle i korzystać z wielu pakietów Oracle (PL/SQL). System n-tieru jest wykonywany za pomocą RemObjects, co oznacza, że nasz klient nie ma w nim żadnego SQL i potrzebuje tylko możliwości wysyłania żądań HTTP, bez nakładów na instalację.
Wszystko to odbywa się za pomocą Borland Delphi i od dwóch lat działa w środowisku produkcyjnym.
Używamy podejście mieszane, w zależności od tego, co będzie pasować do konkretnej sytuacji w aplikacji:
To z Java/Oracle.
Używamy Delphi i Oracle Data Access Components (ODAC) i ADO przez Oracle.OleDBProvider.
Jednym z ulubionych sposobów jest użycie Smalltalk z repozytorium obiektów GemStone. Czemu? Brak problemu z ORMem. Zastanowiłabym się tylko o coś innego, gdyby został wymuszony lub zagrożony przez mojego pracodawcę.
Moim ulubionym sposobem jest posiadanie warstwy abstrakcji obiektu. Idealnie jest to miejsce, które działa z SQL. Ale w praktyce obiekty czasami muszą również wykonywać operacje SQL-y. Ale nic poza obiektem.
Do tej pory sam napisałem takie warstwy, ponieważ dostępne były zbyt niewygodne, zbyt wolne lub zbyt duże.
Używam zwykłego JDBC, ponieważ opracowuję aplikację opartą na danych, a mój model bazy danych jest bardzo złożony. Wszystko jest opisane w bazie danych, nawet struktura innych tabel. Oprócz tego często używam procedur przechowywanych. Dlatego ORM nie jest dla mnie opcją.
Co jeśli chcesz odczytywać 10000 wierszy z bazy danych i przechowywać gdzieś sumę? Po co przeciągać to wszystko przez sieć, kiedy można: wstawić do sum .. wybrać z danych szczegółowych? –
W przypadku ORM nie trzeba czytać 10000 wierszy, aby uzyskać łączną liczbę. Na przykład w LinqToSql możliwe jest użycie metody Sum w celu utworzenia sumy właściwości, która jest następnie konwertowana na odpowiedni SQL, który pozwala serwerowi sql obliczyć sumę bez zwracania wszystkich wierszy. –
@Ole: LinqToSql (który obsługuje tylko SQL Server i może już być martwy na rzecz Entity Framework) nadal jest czarnym pudełkiem, czemu sam nie napisze kodu SQL? A jeśli umieścisz logikę podsumowania w procedurze przechowywanej, nie musisz podawać aplikacji surowego dostępu do twoich tabel. – ObiWanKenobi