Źródło danych obiektu lub jego kod: co jest lepsze?

Question

Wiem, że jest to temat, który może wzbudzić wiele dyskusji, ale chciałbym wiedzieć, co ludzie sądzą o różnych zaletach i wadach korzystania z Object Datasources. Robię teraz projekt z innym programistą, którego doświadczenie i poziom komfortu są zakorzenione w klasycznej ASP, i nie jestem pewien, która droga będzie
a) szybko wykonam zadanie b) załatw pracę z minimalnym zamieszaniem

Mamy ładną warstwę repozytorium z obiektami domeny zdolnymi do samooceny, więc istnieją metody, które umożliwiają wykonanie powiązania ODS lub powiązania kodu.

Nie lubię ODS z większości oczywistych powodów, ale jeśli to mnie uratuje od ręcznego kodowania stronicowania/sortowania/wyboru/wstawiania/aktualizowania/usuwania scenariuszy, to czy naprawdę może być tak źle?

Answer 1

Źródła danych obiektów są dobre dla małych projektów, ale nie są skalowane, ponieważ osadzają informacje warstwy danych w warstwie interfejsu aplikacji. Sugerowałbym, żebyś używał ich tylko w bardzo małych aplikacjach i testach na scratch-pad. Jeśli podejmiesz decyzję projektową, aby z nich skorzystać, przygotuj się do walki z problemami skalowania i konserwacji w przyszłości.

Answer 2

Osobiście uważam, że to zależy od projektu. Jeśli jest to mała aplikacja CRUD z kilkoma stronami, powiązanie ze źródłem danych obiektu będzie prawdopodobnie szybkie, łatwe i będzie miało niewielkie konsekwencje.

Jeśli jest to aplikacja na dużą skalę z dopasowanymi potrzebami, może się okazać, że frustrująca jest próba dopasowania źródła danych obiektu do tych konkretnych potrzeb.

Answer 3

Im lepiej poznasz podstawowy system ADO.NET, tym mniej będziesz mógł polegać na sterowaniu źródłami danych, które są spakowane w Visual Studio. Używałem ich religijnie w pierwszych kilku projektach .NET, nad którymi pracowałem, ale szybko odkryłem, że znacznie lepiej byłoby po prostu korzystać z podstaw łączenia i pobierania danych z bazy danych, niż polegałem na .NET, najlepsza próba zrobienia tego dla mnie.

Patrzę na nie mniej więcej jako kółka szkoleniowe, aby lepiej poznać cykl życia introligatora.

Answer 4

Moim zdaniem oba mają swoje miejsce, swoje mocne i słabe strony. Czas zaoszczędzony na kodowaniu elementów, o których wspominasz, w szczególności na stronicowaniu i sortowaniu, to duża pomoc, ale jeśli chcesz zrobić z nimi coś zdalnie interesującego, szybko stają się bolesne.

Używam ODS, gdy dane będą używane wyłącznie do wyświetlania. Uderz w siatkę danych, ODS i gotowe. Ale jeśli dane muszą być w jakikolwiek sposób zmanipulowane, trzymam się z daleka od wszystkich wbudowanych elementów, bez siatki, bez ODS.

Answer 5

Ogólnie uważam, że kodowanie jest bardziej użyteczne, ponieważ zapewnia centralną lokalizację dostosowywania połączeń z warstwą danych. Dopóki dzielisz akcję na różne warstwy, kod może być bardzo skalowalny.

Z drugiej strony, źródła danych obiektów niestandardowych są bardzo przydatne, ponieważ umożliwiają nieodłączne powiązanie z kontrolką GridView. Zestaw danych dostarczony przez źródło danych obiektu niestandardowego pozwala na łatwe sortowanie i stronicowanie. Obiekt niestandardowy zapewnia również centralną lokalizację dostępu do warstw danych.

Answer 6

Największa zaleta DataSourceControls polega na tym, że eliminują kilka problemów związanych z cyklem życia .NET, zapewniając jednocześnie obsługę pełnego CRUD i dwukierunkowego wyrażenia danych, tj.<% # Bind ("FirstName")%> (jednak 2-drożne wiązanie danych jest do niczego podobne, więc prawdopodobnie niczego nie tracisz). Jako wzorzec projektowy, jest to całkiem niezły pomysł ze średnią implementacją (podobnie jak sam WebForms).

Jeśli wyłączysz stan widoku i spróbujesz obliczyć, dlaczego nie są obsługiwane twoje posty zwrotne, lub musisz zadzwonić do funkcji DataBind() w kilku miejscach, źródła danych mogą zabrać trochę bólu głowy, ponieważ DataBoundControls są na tyle sprytne, aby wiedzieć, kiedy potrzebują danych i po prostu żądają tego od źródła danych. Brak wywołań DataBind().

DataSources to również dobry sposób na sortowanie, filtrowanie i stronicowanie. Większość programistów, gdy używają kodu źródłowego, zwykle nie robi stronicowania, a zamiast tego wraca z bazy danych ogromnych zestawów wyników.

Wadą źródeł danych jest to, że nie było wielu dobrych wdrożeń. Zwykle kończysz wiązanie swojego interfejsu WWW z implementacją trwałości (np. SqlDataSource, LinqDataSource, itp.) Lub w końcu korzystasz z ObjectDataSource, który jest do bani, ponieważ jest tak ograniczony, wymaga zawężonych nazw klas i nazw metod do twojego ASPXa i używa refleksji nieco nieefektywnie. Z tego powodu nie jest to przydatne dla osób stosujących wstrzyknięcia zależności lub statyczne klasy DAO. Jest to dość źle pomyślana klasa i wydaje się prawie jak spostrzeżenie przez MS.

Osobiście wolałbym używać źródeł danych i kodu źródłowego. Użyj źródła danych, aby usunąć ból głowy cyklu życia/widoku, a następnie udostępnij mu zdarzenie "Wybierz/delegowanie" w kodzie źródłowym. Niestety obiekt ObjectDataSource może używać tylko refleksji, jednak można łatwo napisać własną implementację. Mam jeden z moich, ale nie jest publiczny. Jednak zanim napisałem go użyłem tego, co stanowi dla niektórych niedoskonałości ObjectDataSource za:

http://mikeoff.blogspot.com/2006/06/objectdatasource-working-alternative.html

Answer 7

ObjectDataSource jak każdy inny xxxDatasource w WebForms jest koordynatorem między warstwy biznesowej na dużych aplikacji (lub warstwa dostępu do danych na mniejsze) i same kontrole.

To tylko dostarczanie danych i innych funkcji do wizualnej części aplikacji, interfejs użytkownika oparty na widokach w magazynie danych.

Użytkownicy powinni widzieć te kontrolki jako żądania i odpowiedzi dotyczące rzeczy interfejsu użytkownika i przestać je nadużywać lub całkowicie je odrzucić. Nie są one DAL, nie są złe, są tylko połączeniami do źródeł danych, które kontrolują umiejętność mówienia bardzo sprawnie.

Jeśli masz na przykład siatkę danych, która zmienia jej źródło na podstawie decyzji, należy skonfigurować dwa źródła danych obiektu i ta decyzja powinna znajdować się na stronie, a nie w ObjectDatasource. Jest to preferowany sposób korzystania z nich i uniknięcia problemów, które ludzie próbują odnieść w innych odpowiedziach.