Naprawdę muszę zobaczyć uczciwą, przemyślaną debatę na temat zalet obecnie akceptowanychAplikacja korporacyjna paradygmat projektowania.

Nie jestem przekonany, że obiekty istoty powinny istnieć.

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

Moja obecna filozofia projektowania to:

Cały dostęp do bazy danych musi być realizowany za pomocą procedur składowanych.Gdy potrzebujesz danych, wywołaj procedurę przechowywaną i iteruj po SqlDataReader lub wierszach w DataTable

(Uwaga: Zbudowałem także aplikacje korporacyjne z Java EE, java ludzie powinni zastąpić equvalent dla moich przykładów .NET)

Nie jestem anty-OO. Piszę dużo zajęć dla różnych celów, a nie dla jednostek. Przyznam, że duża 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, nazwij to.

Użyłem OR Mapperów. Napisałem kilka. Użyłem stosu Java EE, CSLA i kilku innych odpowiedników. Nie tylko ich używałem, ale aktywnie rozwijałem i utrzymywałem te aplikacje w środowiskach produkcyjnych.

Doszedłem do sprawdzonego w bitwie wniosku, że obiekty bytu wchodzą nam w drogę, a nasze życie będziewięc dużo łatwiej bez nich.

Rozważmy ten prosty przykład: otrzymujesz wezwanie pomocy technicznej dotyczące określonej strony w aplikacji, która nie działa poprawnie, być może jedno z pól nie jest utrwalane tak, jak powinno być. W moim modelu otwiera się programista przypisany do znalezienia problemudokładnie 3 pliki. ASPX, ASPX.CS i plik SQL z procedurą składowaną. Problem, który może być brakującym parametrem w wywołaniu procedury składowanej, zajmuje kilka minut. Jednak w przypadku każdego modelu encji niezmiennie uruchomisz debuger, zaczniesz przechodzić przez kod, i możesz skończyć z 15-20 plikami otwartymi w Visual Studio. Zanim zejdziesz na dół stosu, zapomniałeś, gdzie zacząłeś. Możemy przechowywać tak wiele rzeczy w naszych głowach jednocześnie. Oprogramowanie jest niezwykle złożone bez dodawania niepotrzebnych warstw.

Złożoność rozwoju i rozwiązywanie problemów to tylko jedna z moich stron.

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ć dokładną analizę dokładnego wpływu na bazę danych? I nie tylko kopia rozwojowa, mam na myśli naśladownictwo produkcji, więc widać, że dodatkowa kolumna, której teraz potrzebujesz dla obiektu, po prostu unieważniła bieżący plan zapytań, a raport, który był uruchomiony w ciągu 1 sekundy, będzie teraz trwał 2 minuty ponieważ dodałeś pojedynczą kolumnę do listy wyboru? Okazuje się, że indeks, którego teraz potrzebujesz, jest tak duży, że DBA będzie musiał zmodyfikować fizyczny układ plików?

Jeśli pozwolisz ludziom zbyt daleko od fizycznego magazynu danych z abstrakcją, stworzą spustoszenie w aplikacji, która wymaga skalowania.

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

[Edytować]

Wygląda na to, że to pytanie jest ponownie aktywne, więc teraz, gdy mamy nową funkcję komentarza, skomentowałem bezpośrednio kilka odpowiedzi. Dzięki za odpowiedzi, myślę, że to zdrowa dyskusja.

Prawdopodobnie powinienem był wiedzieć, że mówię o aplikacjach dla przedsiębiorstw. Naprawdę nie mogę komentować, powiedzmy, gry działającej na czyimś komputerze lub aplikacji mobilnej.

Jedna rzecz, którą muszę tu umieścić na górze, w odpowiedzi na kilka podobnych odpowiedzi: ortogonalność i separacja obaw często są wymieniane jako powody, dla których warto przejść do jednostki / ORM. Procedury składowane są dla mnie najlepszym przykładem rozdzielenia obaw, o których myślę. Jeśli zabronisz dostępu do bazy danych w inny sposób niż za pomocą procedur zapisanych w bazie, teoretycznie możesz przeprojektować cały model danych i nie łamać żadnego kodu, o ile zachowasz wejścia i wyjścia procedur przechowywanych. Są doskonałym przykładem programowania według kontraktu (tak długo, jak unikasz „wybierz *” i dokumentuj zestawy wyników).

Zapytaj kogoś, kto był w branży przez długi czas i pracował z długotrwałymi aplikacjami: ile warstw aplikacji i interfejsu użytkownika pojawiło się i zniknęło, gdy baza danych nadal funkcjonowała? Jak trudno jest dostroić i zmienić bazę danych, gdy istnieją 4 lub 5 różnych warstw trwałości generujących SQL, aby uzyskać dane? Nie możesz niczego zmienić! ORM lub dowolny kod generujący SQLzablokuj swoją bazę w kamieniu.