Dlaczego potrzebujemy obiektów bytów? [Zamknięte]

Naprawdę potrzebuję uczciwej, przemyślanej debaty na temat zalet obecnie przyjętego paradygmatu projektowania aplikacji korporacyjnych .

Nie jestem przekonany, że obiekty bytów powinny istnieć.

Przez obiekty encji mam na myśli typowe rzeczy, które zwykle tworzymy dla naszych aplikacji, takie jak „Osoba”, „Konto”, „Zamówienie” itp.

Moja obecna filozofia projektowania jest następująca:

• Cały dostęp do bazy danych musi być realizowany za pośrednictwem procedur składowanych.
• Zawsze, gdy potrzebujesz danych, wywołaj procedurę składowaną i wykonaj iterację po SqlDataReader lub wierszach w DataTable

(Uwaga: stworzyłem również aplikacje korporacyjne w Javie EE, ludzie java proszę zastąpić równoważnik dla moich przykładów .NET)

Nie jestem anty-OO. Piszę wiele zajęć do różnych celów, ale nie do jednostek. Przyznam, że spora część klas, które piszę, to statyczne klasy pomocnicze.

Nie buduję zabawek. Mówię o dużych aplikacjach transakcyjnych o dużej objętości, wdrażanych na wielu komputerach. Aplikacje internetowe, usługi Windows, usługi internetowe, interakcja b2b, możesz to nazwać.

Użyłem OR Mappers. Napisałem kilka. Użyłem stosu Java EE, CSLA i kilku innych odpowiedników. Nie tylko z nich korzystałem, ale aktywnie rozwijałem i utrzymywałem te aplikacje w środowiskach produkcyjnych.

Doszedłem do sprawdzonego w walce wniosku, że obiekty istot wchodzą nam w drogę i bez nich nasze życie byłoby o wiele łatwiejsze.

Rozważmy ten prosty przykład: otrzymujesz telefon do pomocy technicznej dotyczący pewnej strony w aplikacji, która nie działa poprawnie, być może jedno z pól nie jest utrwalane tak, jak powinno. W moim modelu programista wyznaczony do znalezienia problemu otwiera dokładnie 3 pliki . ASPX, ASPX.CS i plik SQL z procedurą składowaną. Rozwiązanie problemu, który może być brakującym parametrem wywołania procedury składowanej, zajmuje kilka minut. Ale w przypadku dowolnego modelu jednostki niezmiennie uruchomisz debuger, zaczniesz przechodzić przez kod i możesz skończyć z 15-20 plikami otwartymi w programie Visual Studio. Kiedy zszedłeś na sam dół stosu, zapomniałeś, od czego zacząłeś. Możemy trzymać w głowie tylko tyle rzeczy naraz. Oprogramowanie jest niesamowicie złożone bez dodawania niepotrzebnych warstw.

Złożoność programowania i rozwiązywanie problemów to tylko jedna strona mojego problemu.

Porozmawiajmy teraz o skalowalności.

Czy programiści zdają sobie sprawę, że za każdym razem, gdy piszą lub modyfikują dowolny kod, który współdziała z bazą danych, muszą przeprowadzić dogłębną analizę dokładnego wpływu na bazę danych? I to nie tylko kopia programistyczna, mam na myśli naśladownictwo produkcji, więc możesz zobaczyć, że dodatkowa kolumna, której teraz potrzebujesz dla swojego obiektu, właśnie unieważniła bieżący plan zapytań, a raport, który był uruchomiony w 1 sekundę, zajmie teraz 2 minuty, tylko ponieważ dodałeś jedną kolumnę do listy wyboru? I okazuje się, że indeks, którego teraz potrzebujesz, jest tak duży, że DBA będzie musiał zmodyfikować fizyczny układ twoich plików?

Jeśli pozwolisz ludziom oddalić się zbytnio od fizycznego magazynu danych z abstrakcją, sieją spustoszenie w aplikacji, która wymaga skalowania.

Nie jestem fanatykiem. Mogę być przekonany, że się mylę, a może jestem, ponieważ jest tak silny nacisk na Linq do Sql, ADO.NET EF, Hibernate, Java EE itp. Proszę przemyśleć swoje odpowiedzi, jeśli czegoś mi brakuje. naprawdę chcę wiedzieć, co to jest i dlaczego powinienem zmienić sposób myślenia.

[Edytować]

Wygląda na to, że to pytanie nagle znów się uaktywniło, więc teraz, gdy mamy nową funkcję komentowania, skomentowałem bezpośrednio kilka odpowiedzi. Dzięki za odpowiedzi, myślę, że to zdrowa dyskusja.

Powinienem był chyba wyraźniej powiedzieć, że mówię o aplikacjach korporacyjnych. Naprawdę nie mogę komentować, powiedzmy, gry działającej na czyimś komputerze stacjonarnym lub aplikacji mobilnej.

Jedna rzecz, którą muszę tutaj umieścić na górze w odpowiedzi na kilka podobnych odpowiedzi: ortogonalność i oddzielenie obaw często są wymieniane jako powody, dla których warto przejść na podmiot / ORM. Procedury składowane są dla mnie najlepszym przykładem rozdzielenia problemów, jakie przychodzą mi do głowy. Jeśli nie zezwolisz na dostęp do bazy danych w inny sposób niż za pośrednictwem procedur składowanych, możesz teoretycznie przeprojektować cały model danych i nie złamać żadnego kodu, o ile zachowasz dane wejściowe i wyjściowe procedur składowanych. Są doskonałym przykładem programowania na podstawie kontraktu (pod warunkiem, że unikasz „select *” i dokumentujesz zestawy wyników).

Zapytaj kogoś, kto jest w branży od dawna i pracował z długotrwałymi aplikacjami: ile warstw aplikacji i interfejsu użytkownika pojawiło się i zniknęło, gdy baza danych żyła? Jak trudne jest dostrojenie i refaktoryzacja bazy danych, gdy istnieje 4 lub 5 różnych warstw trwałości generujących kod SQL w celu uzyskania danych? Nie możesz niczego zmienić! ORMy lub dowolny kod, który generuje SQL, blokuje bazę danych w kamieniu .

Myślę, że wszystko sprowadza się do tego, jak skomplikowana jest „logika” aplikacji i gdzie ją wdrożyłeś. Jeśli cała logika znajduje się w procedurach składowanych, a aplikacja wywołuje te procedury i wyświetla wyniki, to tworzenie obiektów encji jest rzeczywiście stratą czasu. Jednak w przypadku aplikacji, w której obiekty mają ze sobą bogate interakcje, a baza danych jest tylko mechanizmem trwałości, posiadanie tych obiektów może mieć wartość.

Więc powiedziałbym, że nie ma jednej odpowiedzi dla wszystkich. Deweloperzy muszą być świadomi, że czasami próba bycia zbyt OO może spowodować więcej problemów niż rozwiązuje.

Teoria mówi, że wysoce spójne, luźno powiązane implementacje to droga naprzód.

Więc przypuszczam, że kwestionujesz to podejście, a mianowicie oddzielenie obaw.

Czy mój plik aspx.cs powinien współdziałać z bazą danych, wywoływać sproc i rozumieć IDataReader?

W środowisku zespołowym, zwłaszcza gdy masz mniej technicznych ludzi zajmujących się częścią aspx aplikacji, nie potrzebuję, aby ci ludzie mogli „dotykać” tych rzeczy.

Oddzielenie domeny od bazy danych chroni mnie przed zmianami strukturalnymi w bazie, na pewno dobra rzecz? Pewna skuteczność bazy danych jest absolutnie ważna, więc niech ktoś, kto jest najlepszy w tej dziedzinie, zajmie się tą sprawą w jednym miejscu, z jak najmniejszym wpływem na resztę systemu.

O ile nie rozumiem twojego podejścia, jedna strukturalna zmiana w bazie danych może mieć duży wpływ na powierzchnię twojej aplikacji. Widzę, że to rozdzielenie obaw pozwala mi i mojemu zespołowi to zminimalizować. Również każdy nowy członek zespołu powinien lepiej zrozumieć to podejście.

Wydaje się również, że Twoje podejście zaleca, aby logika biznesowa Twojej aplikacji znajdowała się w bazie danych? Wydaje mi się to złe, SQL jest naprawdę dobry w odpytywaniu danych, a nie, imho, wyrażaniu logiki biznesowej.

Ciekawa myśl, chociaż wydaje mi się, że jest o krok od SQL w aspx, który z moich złych, starych, niestrukturalnych dni ASP, napawa mnie lękiem.

Jeden powód - oddzielenie modelu domeny od modelu bazy danych.

Używam programowania sterowanego testami, więc najpierw piszę mój interfejs użytkownika i warstwy modelu, a warstwa danych jest symulowana, więc interfejs użytkownika i model są budowane wokół obiektów specyficznych dla domeny, a później mapuję te obiekty na technologię, której używam Warstwa danych. To zły pomysł, aby struktura bazy danych określała projekt aplikacji. Tam, gdzie to możliwe, najpierw napisz aplikację i pozwól, aby wpłynęło to na strukturę Twojej bazy danych, a nie na odwrót.

Dla mnie sprowadza się to do tego, że nie chcę, aby moja aplikacja zajmowała się sposobem przechowywania danych. Prawdopodobnie dostanę klapsa za to, że to powiedziałem ... ale twoja aplikacja nie jest twoimi danymi, dane są artefaktem aplikacji. Chcę, aby moja aplikacja myślała w kategoriach klientów, zamówień i pozycji, a nie technologii takiej jak DataSets, DataTables i DataRows ... bo kto wie, jak długo będą one dostępne.

Zgadzam się, że zawsze istnieje pewne sprzężenie, ale wolę, aby to sprzęgło sięgało w górę, a nie w dół. Mogę ulepszyć konary i liście drzewa łatwiej niż zmienić jego pień.

Zwykle rezerwuję sprocy do raportowania, ponieważ zapytania stają się trochę bardziej nieprzyjemne niż ogólny dostęp do danych w aplikacji.

Wydaje mi się również, że przy odpowiednim wczesnym testowaniu jednostkowym w tym scenariuszu jedna kolumna nie zostanie utrwalona, ​​prawdopodobnie nie będzie problemem.

Eric, jesteś martwy. W przypadku każdej naprawdę skalowalnej / łatwej w utrzymaniu / solidnej aplikacji jedyną prawdziwą odpowiedzią jest pozbycie się wszystkich śmieci i trzymanie się podstaw.

Podążałem podobną trajektorią w mojej karierze i doszedłem do tych samych wniosków. Oczywiście jesteśmy uważani za heretyków i wyglądaliśmy na śmiesznych. Ale moje rzeczy działają i działają dobrze.

Każdy wiersz kodu należy traktować podejrzliwie.

Chciałbym odpowiedzieć przykładem podobnym do tego, który zaproponowałeś.

W mojej firmie musiałem zbudować prostą sekcję CRUD dla produktów, buduję wszystkie moje byty i osobny DAL. Później inny programista musiał zmienić powiązaną tabelę, a nawet zmienił nazwy kilku pól. Jedynym plikiem, który musiałem zmienić, aby zaktualizować mój formularz, był DAL dla tej tabeli.

Co (moim zdaniem) wnoszą do projektu podmioty:

Ortogonalność: Zmiany w jednej warstwie mogą nie wpływać na inne warstwy (oczywiście, jeśli dokonasz ogromnej zmiany w bazie danych, przejdą one przez wszystkie warstwy, ale większość małych zmian nie).

Testowalność: możesz przetestować swoją logikę bez dotykania bazy danych. Zwiększa to wydajność testów (umożliwiając częstsze ich uruchamianie).

Rozdzielenie obaw: w dużym produkcie możesz przypisać bazę danych do administratora danych, a on może zoptymalizować ją do diabła. Przypisz Model do eksperta biznesowego, który ma wiedzę niezbędną do jego zaprojektowania. Przypisz indywidualne formularze programistom bardziej doświadczonym w obsłudze formularzy internetowych itp.

Na koniec chciałbym dodać, że większość maperów ORM obsługuje procedury składowane, ponieważ tego właśnie używasz.

Twoje zdrowie.

Myślę, że na ten temat możesz „gryźć więcej niż możesz przeżuć”. Ted Neward nie był nonszalancki, kiedy nazwał to „ Wietnamem informatyki ”.

Jedyną rzeczą, którą mogę absolutnie zagwarantować, jest to, że nie zmieni to niczyjego punktu widzenia w tej sprawie, co zostało wielokrotnie udowodnione na niezliczonych innych blogach, forach, podcastach itp.

Z pewnością w porządku jest mieć otwartą dyskusję i debatę na kontrowersyjny temat, po prostu ten temat był robiony tyle razy, że obie „strony” zgodziły się nie zgodzić i po prostu zajęły się pisaniem oprogramowania.

Jeśli chcesz poczytać po obu stronach, przeczytaj artykuły na blogu Teda, Ayende Rahein, Jimmy Nilson, Scott Bellware, Alt.Net, Stephen Forte, Eric Evans itp.

@Dan, przepraszam, nie tego szukam. Znam teorię. Twoje stwierdzenie „to bardzo zły pomysł” nie jest poparte prawdziwym przykładem. Staramy się tworzyć oprogramowanie w krótszym czasie, mniej ludzi, mniej błędów i chcemy mieć możliwość łatwego wprowadzania zmian. Twój model wielowarstwowy, z mojego doświadczenia, jest negatywny we wszystkich powyższych kategoriach. Zwłaszcza jeśli chodzi o uczynienie modelu danych ostatnią rzeczą, którą robisz. Fizyczny model danych musi być ważnym zagadnieniem od pierwszego dnia.

Twoje pytanie jest naprawdę interesujące.
Zwykle potrzebuję obiektów encji, aby hermetyzować logikę biznesową aplikacji. Przeniesienie tej logiki do warstwy danych byłoby naprawdę skomplikowane i nieodpowiednie.
Co byś zrobił, aby uniknąć tych obiektów obiektów? Jakie rozwiązanie masz na myśli?

Obiekty Entity mogą ułatwić buforowanie w warstwie aplikacji. Powodzenia w buforowaniu danych.

Powinniśmy również porozmawiać o tym, czym naprawdę są byty. Kiedy czytam tę dyskusję, mam wrażenie, że większość ludzi tutaj patrzy na byty w sensie anemicznego modelu domeny . Wiele osób uważa model domeny anemicznej za anty-wzór!

Bogate modele dziedzinowe mają wartość. O to właśnie chodzi w Domain Driven Design . Osobiście uważam, że OO to sposób na pokonanie złożoności. Oznacza to nie tylko złożoność techniczną (jak dostęp do danych, powiązanie interfejsu użytkownika, bezpieczeństwo ...), ale także złożoność w dziedzinie biznesowej !

Jeśli możemy zastosować techniki OO do analizy, modelowania, projektowania i wdrażania naszych problemów biznesowych, jest to ogromna zaleta pod względem łatwości utrzymania i rozszerzalności nietrywialnych aplikacji!

Istnieją różnice między Twoimi encjami a tabelami. Encje powinny reprezentować Twój model, a tabele tylko reprezentują aspekt danych Twojego modelu!

Prawdą jest, że dane żyje dłużej niż aplikacje, ale za to cytat z Davida Laribee : Modele są zawsze ... dane jest szczęśliwym efektem ubocznym.

Więcej linków na ten temat:

• Dlaczego setery i gettery są złe

• Powrót czystego OO

• POJO kontra NOJO

• Super modele, część 2

• TDD, Mocks and Design

Naprawdę interesujące pytanie. Szczerze mówiąc, nie potrafię udowodnić, dlaczego byty są dobre. Ale mogę podzielić się opinią, dlaczego je lubię. Kod jak

void exportOrder(Order order, String fileName){...};

nie przejmuje się tym, skąd pochodzi kolejność - z DB, z żądania internetowego, z testu jednostkowego itp. To sprawia, że ​​ta metoda wyraźniej deklaruje, czego dokładnie wymaga, zamiast pobierać DataRow i dokumentować, które kolumny oczekuje i które typy powinny być. To samo dotyczy sytuacji, gdy zaimplementujesz go w jakiś sposób jako procedurę składowaną - nadal musisz wypchnąć do niego identyfikator rekordu, podczas gdy nie musi on być obecny w DB.

Implementacja tej metody odbywałaby się na podstawie abstrakcji Order, a nie na podstawie tego, jak dokładnie jest ona prezentowana w DB. Większość takich operacji, które zaimplementowałem, tak naprawdę nie zależy od sposobu przechowywania tych danych. Rozumiem, że niektóre operacje wymagają sprzężenia ze strukturą DB ze względu na wydajność i skalowalność, ale z mojego doświadczenia wynika, że ​​nie ma ich zbyt wiele. Z mojego doświadczenia bardzo często wystarczy wiedzieć, że .getFirstName () zwraca String, a .getAddress () zwraca Adres, a adres ma .getZipCode () itd. - i nie obchodzi mnie, które tabele są odpowiedzialne za przechowywanie tych danych .

Jeśli masz do czynienia z opisanymi przez Ciebie problemami, na przykład gdy dodatkowe przerwy w kolumnach raportują wykonanie, to DB jest częścią krytyczną dla twoich zadań i rzeczywiście powinieneś być jak najbliżej tego. Chociaż encje mogą dostarczać wygodnych abstrakcji, mogą również ukrywać niektóre ważne szczegóły.

Skalowalność jest tutaj interesująca - większość stron internetowych, które wymagają ogromnej skalowalności (jak facebook, livejournal, flickr), ma tendencję do stosowania ascetycznego podejścia DB, gdy DB jest używany tak rzadko, jak to możliwe, a problemy ze skalowalnością rozwiązuje się przez buforowanie, szczególnie przez użycie pamięci RAM. http://highscalability.com/ zawiera kilka interesujących artykułów na ten temat.

Istnieją inne dobre powody dla obiektów bytów poza abstrakcją i luźnymi powiązaniami. Jedną z rzeczy, które lubię najbardziej, jest mocne pisanie, którego nie można uzyskać za pomocą DataReader lub DataTable. Innym powodem jest to, że po dobrym wykonaniu odpowiednie klasy jednostek mogą sprawić, że kod będzie łatwiejszy w utrzymaniu, używając konstrukcji pierwszej klasy dla terminów specyficznych dla domeny, które każdy, kto patrzy na kod, prawdopodobnie zrozumie, zamiast używać zestawu ciągów znaków z nazwami pól. do indeksowania DataRow. Procedury składowane są naprawdę ortogonalne w stosunku do ORM, ponieważ wiele struktur mapowania daje możliwość mapowania na sprocs.

Nie uważałbym sprocs + datareaders za substytut dobrego ORM. W przypadku procedur składowanych nadal jesteś ograniczony i ściśle powiązany z sygnaturą typu procedury, która używa innego systemu typów niż kod wywołujący. Procedury składowane mogą podlegać modyfikacjom w celu uwzględnienia dodatkowych opcji i zmian schematu. Alternatywą dla procedur składowanych w przypadku, gdy schemat podlega zmianie, jest użycie widoków - można mapować obiekty do widoków, a następnie ponownie mapować widoki do tabel bazowych po ich zmianie.

Rozumiem twoją niechęć do ORM, jeśli twoje doświadczenie składa się głównie z Java EE i CSLA. Możesz chcieć rzucić okiem na LINQ to SQL, które jest bardzo lekką strukturą i jest przede wszystkim mapowaniem jeden do jednego z tabelami bazy danych, ale zwykle wymaga tylko niewielkiego rozszerzenia, aby były w pełni rozwiniętymi obiektami biznesowymi. LINQ to SQL może również mapować obiekty wejściowe i wyjściowe na parametry i wyniki procedur składowanych.

Struktura ADO.NET Entity ma tę dodatkową zaletę, że tabele bazy danych można wyświetlać jako klasy jednostek dziedziczące po sobie lub jako kolumny z wielu tabel zagregowanych w jedną jednostkę. Jeśli chcesz zmienić schemat, możesz zmienić mapowanie z modelu koncepcyjnego na schemat magazynu bez zmiany rzeczywistego kodu aplikacji. I znowu można tutaj użyć procedur składowanych.

Myślę, że więcej projektów informatycznych w przedsiębiorstwach kończy się niepowodzeniem z powodu niemożności utrzymania kodu lub słabej produktywności programistów (co może się zdarzyć np. Z przełączania kontekstu między pisaniem sprocesora a pisaniem aplikacji) niż problemy ze skalowalnością aplikacji.

Chciałbym również dodać do odpowiedzi Dana, że oddzielenie obu modeli umożliwiłoby uruchomienie aplikacji na różnych serwerach baz danych, a nawet modelach baz danych.

A co, jeśli musisz skalować swoją aplikację, równoważąc obciążenie więcej niż jednego serwera internetowego? Możesz zainstalować pełną aplikację na wszystkich serwerach WWW, ale lepszym rozwiązaniem jest połączenie serwerów WWW z serwerem aplikacji.

Ale jeśli nie ma żadnych obiektów bytów, nie będą miały zbyt wiele do omówienia.

Nie mówię, że nie powinieneś pisać monolitów, jeśli jest to prosta, wewnętrzna aplikacja o krótkim czasie życia. Ale gdy tylko stanie się umiarkowanie złożona lub powinna trwać przez dłuższy czas, naprawdę musisz pomyśleć o dobrym projekcie.

Oszczędza to czas, jeśli chodzi o jego konserwację.

Oddzielając logikę aplikacji od logiki prezentacji i dostępu do danych oraz przekazując między nimi DTO, można je oddzielić. Umożliwienie im samodzielnej zmiany.

Ten post na comp.object może Cię zainteresować.

Nie twierdzę, że się zgadzam lub nie, ale jest to interesujące i (myślę) istotne dla tego tematu.

Pytanie: Jak radzisz sobie z odłączonymi aplikacjami, jeśli cała logika biznesowa jest uwięziona w bazie danych?

W interesującym mnie typie aplikacji Enterprise mamy do czynienia z wieloma lokacjami, niektóre z nich muszą być w stanie funkcjonować w stanie rozłączonym.
Jeśli logika biznesowa jest hermetyzowana w warstwie domeny, którą można łatwo włączyć do różnych typów aplikacji - powiedzmy, jako dll- to mogę tworzyć aplikacje, które są świadome reguł biznesowych i w razie potrzeby mogą je stosować lokalnie.

Utrzymując warstwę domeny w procedurach składowanych w bazie danych, musisz trzymać się jednego typu aplikacji, która wymaga stałego dostępu do bazy danych.

Jest w porządku dla określonej klasy środowisk, ale z pewnością nie obejmuje całego spektrum aplikacji korporacyjnych .

@jdecuyper, często powtarzam sobie maksymę: „jeśli logiki biznesowej nie ma w bazie danych, jest to tylko zalecenie”. Myślę, że Paul Nielson powiedział to w jednej ze swoich książek. Warstwy aplikacji i interfejs użytkownika pojawiają się i znikają, ale dane zwykle żyją bardzo długo.

Jak unikać obiektów encji? Przeważnie procedury składowane. Przyznaję również, że logika biznesowa ma tendencję do przenikania przez wszystkie warstwy aplikacji, czy tego chcesz, czy nie. Pewna ilość sprzężeń jest nieodłączna i nieunikniona.

Ostatnio dużo o tym myślałem; Przez jakiś czas intensywnie korzystałem z CSLA i uwielbiam czystość stwierdzenia, że ​​„cała Twoja logika biznesowa (lub przynajmniej tyle, na ile jest to racjonalnie możliwe) jest zamknięta w jednostkach biznesowych”.

Widziałem, że model jednostki biznesowej zapewnia dużą wartość w przypadkach, gdy projekt bazy danych różni się od sposobu pracy z danymi, co ma miejsce w przypadku wielu programów biznesowych.

Na przykład idea „klienta” może składać się z głównego rekordu w tabeli Klientów, połączonego ze wszystkimi zamówieniami złożonymi przez klienta, jak również z wszystkimi pracownikami klienta i ich danymi kontaktowymi, a także z niektórymi właściwościami klienta i jego elementy podrzędne można określić na podstawie tabel przeglądowych. To naprawdę fajne z punktu widzenia programisty, móc pracować z Klientem jako pojedynczą jednostką, ponieważ z biznesowego punktu widzenia koncepcja Klienta obejmuje wszystkie te elementy, a relacje mogą być egzekwowane w bazie danych lub nie.

Chociaż doceniam cytat, że „jeśli Twojej reguły biznesowej nie ma w bazie danych, to tylko sugestia”, uważam również, że nie powinieneś projektować bazy danych w celu egzekwowania reguł biznesowych, powinieneś zaprojektować ją tak, aby była wydajna, szybka i znormalizowana .

To powiedziawszy, jak zauważyli inni powyżej, nie ma „idealnego projektu”, narzędzie musi pasować do zadania. Jednak korzystanie z jednostek biznesowych może naprawdę pomóc w utrzymaniu i produktywności, ponieważ wiesz, gdzie się udać, aby zmodyfikować logikę biznesową, a obiekty mogą modelować rzeczywiste koncepcje w intuicyjny sposób.

Eric,

Nikt nie powstrzymuje Cię przed wybraniem struktury / podejścia, które chcesz. Jeśli masz zamiar przejść ścieżką opartą na danych / procedurach składowanych, to zdecydowanie idź! Zwłaszcza jeśli naprawdę pomaga dostarczać aplikacje zgodnie ze specyfikacją i na czas.

Jedynym zastrzeżeniem jest to (druga strona pytania), WSZYSTKIE reguły biznesowe powinny dotyczyć procedur składowanych, a aplikacja jest niczym innym jak cienkim klientem.

Mając to na uwadze, obowiązują te same zasady, jeśli składasz wniosek w trybie OOP: bądź konsekwentny. Postępuj zgodnie z zasadami OOP, co obejmuje tworzenie obiektów encji do reprezentowania modeli domeny.

Jedyną prawdziwą zasadą jest tutaj spójność słów . Nikt nie powstrzymuje Cię przed przejściem na DB-centric. Nikt nie powstrzymuje Cię od wykonywania programów o strukturze starej szkoły (czyli programów funkcjonalnych / proceduralnych). Do diabła, nikt nikogo nie powstrzymuje przed tworzeniem kodu w stylu COBOL. ALE aplikacja musi być bardzo, bardzo konsekwentna, gdy idzie tą ścieżką, jeśli chce osiągnąć jakikolwiek sukces.

Naprawdę nie jestem pewien, co uważasz za „aplikacje dla przedsiębiorstw”. Ale mam wrażenie, że definiujesz ją jako aplikację wewnętrzną, w której RDBMS zostałby osadzony w kamieniu, a system nie musiałby być interoperacyjny z żadnymi innymi systemami, zarówno wewnętrznymi, jak i zewnętrznymi.

Ale co by było, gdybyś miał bazę danych ze 100 tabelami, co odpowiada 4 procedurom składowanym dla każdej tabeli tylko dla podstawowych operacji CRUD, czyli 400 procedur składowanych, które muszą być obsługiwane i nie są silnie wpisane, więc są podatne na literówki ani nie mogą być testowane jednostkowo . Co się stanie, gdy zdobędziesz nowego CTO, który jest ewangelistą Open Source i chce zmienić RDBMS z SQL Server na MySql?

Obecnie wiele programów, niezależnie od tego, czy aplikacje czy produkty dla przedsiębiorstw korzysta z architektury SOA i ma pewne wymagania dotyczące udostępniania usług internetowych, a przynajmniej takie, którymi jestem i które robię. Korzystając z tego podejścia, można w końcu ujawnić Serialized DataTable lub DataRows. Teraz można to uznać za akceptowalne, jeśli klient ma zagwarantowaną platformę .NET i jest w sieci wewnętrznej. Ale gdy klient nie jest znany, powinieneś dążyć do zaprojektowania interfejsu API, które jest intuicyjne iw większości przypadków nie chcesz udostępniać schematu pełnej bazy danych. Z pewnością nie chciałbym wyjaśniać programiście Java, czym jest DataTable i jak z niego korzystać. Uwzględniono również przepustowość i rozmiar ładunku oraz zserializowane tabele danych. Zestawy danych są bardzo ciężkie.

Nie ma żadnej srebrnej kuli w projektowaniu oprogramowania i tak naprawdę zależy to od tego, gdzie leżą priorytety, dla mnie jest to kod testowany jednostkowo i luźno powiązane komponenty, które mogą być łatwo wykorzystane przez dowolnego klienta.

tylko moje 2 centy

Chciałbym przedstawić inny punkt widzenia na problem odległości między OO a RDB: historię.

Każde oprogramowanie ma model rzeczywistości, który jest w pewnym stopniu abstrakcją rzeczywistości. Żaden program komputerowy nie jest w stanie uchwycić całej złożoności rzeczywistości, a programy są pisane tylko po to, aby rozwiązać zestaw problemów z rzeczywistości. Dlatego każdy model oprogramowania jest redukcją rzeczywistości. Czasami model oprogramowania wymusza redukcję rzeczywistości. Na przykład, gdy chcesz, aby firma wynajmująca samochody zarezerwowała dla Ciebie dowolny samochód, o ile jest niebieski i ma stopy, ale operator nie może spełnić, ponieważ Twoje żądanie nie zmieści się w komputerze.

RDB wywodzi się z bardzo starej tradycji umieszczania informacji w tabelach, zwanej rachunkowością. Księgowość prowadzono na papierze, potem na kartach perforowanych, a potem na komputerach. Ale księgowość już teraz ogranicza rzeczywistość. Rachunkowość zmusiła ludzi do przestrzegania jej systemu tak długo, że stała się akceptowaną rzeczywistością. Dlatego stosunkowo łatwo jest stworzyć oprogramowanie komputerowe do księgowości, księgowość miała swój model informacyjny na długo przed pojawieniem się komputera.

Biorąc pod uwagę znaczenie dobrych systemów księgowych i akceptację ze strony wszystkich menedżerów biznesowych, systemy te stały się bardzo zaawansowane. Podstawy bazy danych są teraz bardzo solidne i nikt nie waha się przechowywać ważnych danych w czymś tak godnym zaufania.

Myślę, że OO musiało się pojawić, kiedy ludzie odkryli, że inne aspekty rzeczywistości są trudniejsze do modelowania niż rachunkowość (która już jest modelem). OO stał się bardzo udanym pomysłem, ale trwałość danych OO jest stosunkowo słabo rozwinięta. RDB / Księgowość ma łatwe wygrane, ale OO to znacznie większa dziedzina (w zasadzie wszystko, co nie jest księgowe).

Tak wielu z nas chciało korzystać z OO, ale nadal chcemy bezpiecznego przechowywania naszych danych. Co może być bezpieczniejszego niż przechowywanie naszych danych w taki sam sposób, jak robi to szacowny system księgowy? To kusząca perspektywa, ale wszyscy napotykamy te same pułapki. Bardzo niewielu zadało sobie trud, by pomyśleć o wytrwałości OO w porównaniu z ogromnymi wysiłkami branży RDB, która skorzystała z tradycji i pozycji księgowości.

Prevayler i db4o to kilka sugestii, jestem pewien, że są inne, o których nie słyszałem, ale żadna nie wydawała się przyciągać połowy prasy jako, powiedzmy, hibernacji.

Przechowywanie obiektów w starych, dobrych plikach nie wydaje się być traktowane poważnie w przypadku aplikacji dla wielu użytkowników, a zwłaszcza aplikacji internetowych.

W mojej codziennej walce o zamknięcie przepaści między OO i RDB używam OO tak często, jak to możliwe, ale staram się ograniczyć dziedziczenie do minimum. Nieczęsto używam SP. Będę używać zaawansowanych zapytań tylko w aspektach, które wyglądają jak rachunkowość.

Będę szczęśliwie zdziwiony, gdy przepaść zostanie zamknięta na dobre. Myślę, że rozwiązanie pojawi się, gdy Oracle uruchomi coś w rodzaju „Oracle Object Instance Base”. Aby naprawdę się pochwalić, musi mieć uspokajającą nazwę.

W tej chwili nie trwało to długo, ale tuż przy mojej głowie ...

Model jednostki pozwala zapewnić spójny interfejs dla bazy danych (i innych możliwych systemów), nawet wykraczający poza możliwości interfejsu procedury składowanej. Korzystając z modeli biznesowych obejmujących całe przedsiębiorstwo, możesz mieć pewność, że wszystkie aplikacje konsekwentnie wpływają na dane, co jest BARDZO ważne. W przeciwnym razie otrzymasz złe dane, co jest po prostu złe.

Jeśli masz tylko jedną aplikację, tak naprawdę nie masz systemu „przedsiębiorstwa”, niezależnie od tego, jak duża jest ta aplikacja lub Twoje dane. W takim przypadku możesz zastosować podejście podobne do tego, o którym mówisz. Po prostu bądź świadomy pracy, która będzie potrzebna, jeśli zdecydujesz się rozwijać swoje systemy w przyszłości.

Oto kilka rzeczy, o których należy pamiętać (IMO):

1. Wygenerowany kod SQL jest zły (należy przestrzegać wyjątków). Przepraszam, wiem, że wiele osób uważa, że ​​to ogromna oszczędność czasu, ale nigdy nie znalazłem systemu, który mógłby generować bardziej wydajny kod niż ten, który mógłbym napisać, a często kod jest po prostu okropny. Często kończy się to również generowaniem mnóstwa kodu SQL, który nigdy nie jest używany. Wyjątkiem są tutaj bardzo proste wzorce, jak może tabele przeglądowe. Jednak wiele osób daje się tym ponieść.
2. Jednostki <> Tabele (lub koniecznie jednostki logicznego modelu danych). Model danych często ma reguły dotyczące danych, które powinny być egzekwowane jak najbliżej bazy danych, które mogą obejmować reguły dotyczące wzajemnych powiązań wierszy tabeli lub inne podobne reguły, które są zbyt skomplikowane dla deklaratywnego RI. Powinny być obsługiwane w procedurach składowanych. Jeśli wszystkie procedury składowane są prostymi procesami CRUD, nie możesz tego zrobić. Ponadto model CRUD zwykle stwarza problemy z wydajnością, ponieważ nie minimalizuje podróży w obie strony przez sieć do bazy danych. To często największe wąskie gardło w aplikacji korporacyjnej.

Czasami aplikacja i warstwa danych nie są ze sobą ściśle powiązane. Na przykład możesz mieć aplikację do rozliczeń telefonicznych. Później tworzysz oddzielną aplikację, która monitoruje użycie telefonu, aby a) lepiej reklamować się b) zoptymalizować swój plan telefoniczny.

Te aplikacje mają różne problemy i wymagania dotyczące danych (nawet dane pochodzą z tej samej bazy danych), mogą sterować różnymi projektami. Twoja baza kodu może skończyć się całkowitym bałaganem (w obu aplikacjach) i koszmarem do utrzymania, jeśli pozwolisz, aby baza danych sterowała kodem.

Aplikacje, które mają logikę domeny oddzieloną od logiki przechowywania danych, można dostosować do dowolnego rodzaju źródła danych (bazy danych lub w inny sposób) lub interfejsu użytkownika (WWW lub Windows (lub linux itp.)).

Prawie utknąłeś w swojej bazie danych, co nie jest złe, jeśli pracujesz w firmie, która jest zadowolona z obecnego systemu bazy danych, którego używasz. Jednak ponieważ bazy danych ewoluują z czasem, może istnieć nowy system baz danych, który jest naprawdę schludny i nowy, z którego chce korzystać Twoja firma. A co by było, gdyby chcieli przełączyć się na metodę dostępu do danych z usług internetowych (tak jak czasami robi to architektura zorientowana na usługi). Może być konieczne przeniesienie procedur składowanych w dowolne miejsce.

Również logika domeny odciąga interfejs użytkownika, co może być ważniejsze w dużych, złożonych systemach, które mają stale ewoluujące interfejsy użytkownika (zwłaszcza gdy stale szukają większej liczby klientów).

Ponadto, chociaż zgadzam się, że nie ma ostatecznej odpowiedzi na pytanie, czy procedury składowane czy logika domeny. Jestem w obozie logiki domeny (i myślę, że z czasem wygrywają), ponieważ uważam, że skomplikowane procedury składowane są trudniejsze do utrzymania niż skomplikowana logika domeny. Ale to zupełnie inna debata

Myślę, że jesteś przyzwyczajony do pisania określonego rodzaju aplikacji i rozwiązywania pewnego rodzaju problemów. Wydaje się, że atakujesz to z perspektywy „najpierw bazy danych”. Istnieje wielu programistów, w których dane są utrwalane w bazie danych, ale wydajność nie jest najwyższym priorytetem. W wielu przypadkach nałożenie abstrakcji na warstwę trwałości znacznie upraszcza kod, a koszt wydajności nie stanowi problemu.

Cokolwiek robisz, nie jest to OOP. To nie jest złe, po prostu nie jest OOP i nie ma sensu stosować rozwiązań do wszystkich innych problemów.

Interesujące pytanie. Kilka myśli:

1. Jak przetestowałbyś jednostkę, gdyby cała logika biznesowa znajdowała się w bazie danych?
2. Czy zmiany w strukturze bazy danych, szczególnie te, które wpływają na kilka stron w aplikacji, nie byłyby dużym kłopotem przy zmianie w całej aplikacji?

Dobre pytanie!

Jedną z metod, które lubię, jest utworzenie obiektu iteratora / generatora, który emituje instancje obiektów, które są istotne dla określonego kontekstu. Zwykle ten obiekt zawija pewne podstawowe rzeczy związane z dostępem do bazy danych, ale nie muszę o tym wiedzieć, kiedy go używam.

Na przykład,

Obiekt AnswerIterator generuje obiekty AnswerIterator.Answer. Pod maską iteruje instrukcję SQL, aby pobrać wszystkie odpowiedzi, i inną instrukcję SQL, aby pobrać wszystkie powiązane komentarze. Ale kiedy używam iteratora, po prostu używam obiektu Answer, który ma minimalne właściwości dla tego kontekstu. Przy odrobinie kodu szkieletowego staje się to prawie trywialne.

Zauważyłem, że działa to dobrze, gdy mam ogromny zbiór danych do pracy, a gdy jest dobrze zrobiony, daje mi małe, przejściowe obiekty, które są stosunkowo łatwe do przetestowania.

Zasadniczo jest to cienka okleina na rzeczy z dostępem do bazy danych, ale nadal daje mi elastyczność abstrakcji, kiedy zajdzie taka potrzeba.

Obiekty w moich aplikacjach zwykle odnoszą się jeden do jednego do bazy danych, ale stwierdzam, że używanie Linq To Sql zamiast sprocs znacznie ułatwia pisanie skomplikowanych zapytań, zwłaszcza możliwość ich tworzenia przy użyciu odroczonego wykonania. np. z r w Images.User.Ratings, gdzie itd. Oszczędza mi to próby wypracowania kilku instrukcji złączenia w sql, a posiadanie funkcji Skip & Take do stronicowania również upraszcza kod, zamiast osadzać kod row_number & „over”.

Po co zatrzymywać się na obiektach bytów? Jeśli nie widzisz wartości z obiektami encji w aplikacji na poziomie przedsiębiorstwa, po prostu wykonaj dostęp do danych w języku czysto funkcjonalnym / proceduralnym i połącz go z interfejsem użytkownika. Dlaczego po prostu nie wyciąć całego „puchu” OO?