Czy w środowisku .NET np. w większych aplikacjach, np. pisanych z użyciem ASP.NET MVC i C#, jest odpowiednik DAO, który pełnij by podobną funkcję jak w JEE. Osobiście widziałem na stronie Microsoftu tworzenie takich obiektów z użyciem odpowiednich zapytań w LINQ do bazy danych, które wynik zapisywały do obiektów DAO, był to jednak starszy artykuł.
Czy aktualnie pisząc aplikacje w ASP.NET stosuje się jeszcze DAO lub jego nowszy odpowiednik ?
DAO to taki odpowiednik Repozytorium. Jest on używany bardzo często ale osobiście wolę wzorce CQS / CQRS
Jak w kodzie, są umieszczane tu obiekty DAO w Model View Controller ( MVC ), czy standordowo powstają w modelu a w kontrolerze przekazywane są do widoku ?
Przy okazji, dopytam logika biznesowa aplikacji tu ( ogólnie o ASP.NET MVC ) zawarta będzie w kontrolerze ?
Pawel412 napisał(a):
Przy okazji, dopytam logika biznesowa aplikacji tu ( ogólnie o ASP.NET MVC ) zawarta będzie w kontrolerze ?
Logika biznesowa absolutnie nie może być w kontrolerze to przeczy całemu wykorzystania wzorca MVC. Model nie stanowi jedynie modelu dziedziny, a jest to warstwa określająca całą logikę biznesową.
Dziękuję czyli w modelu tradycyjnie powstaną DAO i logika biznesowa podobnie jak w JEE.
error91 napisał(a):
DAO to taki odpowiednik Repozytorium.
Nie. Repozytorium co najwyżej może wewnętrznie korzystać z DAO (a może też z ORM, TDG, RDG i pewno jeszcze wielu mi nieznanych podejść). Repozytorium to NIE jest warstwa dostępu do danych.
Czy w ASP.NET Serwisy, które mogą korzystać z ORM lub repozytoriów są odpowiednikiem idei DAO.
Jak w ASP.NET realizuje się idee DAO technicznie, jakimi metodami, może jest ich kilka ? Które są najbardziej popularne ?
Na razie kieruję się ku wykorzystaniu serwisów. i repozytoriów.
Pawel412 napisał(a):
Czy w ASP.NET Serwisy, które mogą korzystać z ORM lub repozytoriów są odpowiednikiem idei DAO.
ORM jest formą DAO. Repozytoria są nad DAO.
Przez serwisy w ASP.NET rozumiem webserwisy. To są aplikacje, które mogą mieć jakąś warstwę danych, mogą nie mieć, mogą mieć logikę biznesową, a mogą być tylko fasadą.
No chyba, że chodziło Ci o klasy-serwisy. To szerokie pojęcie, ale one mogą korzystać z dowolnej warstwy dostępu do danych, zależy jak zaprogramujesz.
Jak w ASP.NET realizuje się idee DAO technicznie, jakimi metodami, może jest ich kilka ? Które są najbardziej popularne ?
Takimi jak w .NET w ogólności. Może to być ORM (EF, NHibernate), może to być mikroORM (Dapper, SimpleData), może to być ADO.NET (SqlCommand/SqlDataReader). A dawno temu używało się DataSetów, obecnie już raczej niespotykane.
Dziękuję, czyli np. EF można potraktować jako automatyczny lub modyfikowalny przez budowę zapytań generator DAO, ale jest to odwzorowanie np. tabel danych ( oczywiście z możliwością przetworzenia danych ) i nie daje nam chyba to możliwości oddzielenia się od struktury danych w tabelach, zmiany w danych będą zmieniać budowę DAO co pociągnie za sobą zmiany wyżej w strukturze kodu mylę się ?
Co masz na myśli w ostatnim pytaniu ?
EF nie jest tylko generatorem DAO (ja to rozumiem jako generator klas modelu). Na dobrą sprawę EF to ORM, generator modelu to tylko jedna z jego przystawek.
Chodzi Ci oto czy stosując EF automat za ciebie zmieni klasy modelu w przypadku gdy zmieni się struktura danych ?
Otóż Microsoft początkowo promował takie podejście - tworzony był schemat tabel (plik .edmx) z niego generowane były klasy. Zawsze można było zrobić Refresh schematu tym samym ponowne wygenerowanie klasy modelu. Było to podejście Database-first.
Obecnie mocniej promowane jest podejście Code-first. To ty piszesz klasy modelu, a z nich jest generowany schemat tabel. Oczywiście możesz wpływać na to jak tabele i kolumny się nazywają, jaką mają długość itd.
Pawel412 napisał(a):
Dziękuję, czyli np. EF można potraktować jako automatyczny lub modyfikowalny przez budowę zapytań generator DAO, ale jest to odwzorowanie np. tabel danych ( oczywiście z możliwością przetworzenia danych ) i nie daje nam chyba to możliwości oddzielenia się od struktury danych w tabelach, zmiany w danych będą zmieniać budowę DAO co pociągnie za sobą zmiany wyżej w strukturze kodu mylę się ?
Dość zagmatwane to zdanie, ale z tego, co zrozumiałem, to pytasz o podejście database-first, o którym wspomniał @Slepiec.
Jeśli generujesz model na podstawie bazy, to owszem, po zmianach jej schematu, trzeba odświeżyć model, co wpłynie na kod. Ale to chyba oczywiste... jak niby miałoby to działać inaczej?
Do tej pory używałem obiektów DAO edukacyjnie i przykładowy obiekt oprócz danych z tabeli lub tabel zawierał pola z nimi powiązane, które były obliczane przez logikę biznesową w modelu ( np. w EJB JEE ), w przypadku EF chyba musiałbym takie pola dodawać do zapytań i obsługiwać funkcjami, to byłyby bardzo skomplikowane zapytania i przejrzystość takiego programowania była by ograniczona ?
Nie, nie musiałbyś. Mógłbyś mieć w klasach pola, które nie są mapowane do tabel i dynamicznie obliczane na podstawie czegoś tam.
A najlepiej jakbyś miał SRP i oddzielony model składowania danych od modelu biznesowego.