Sposób w jaki było
Od lat organizuję swoje rozwiązania programowe jako takie:
- Warstwa dostępu do danych (DAL) w celu wyodrębnienia działalności związanej z dostępem do danych
- Warstwa logiki biznesowej (BLL) do stosowania reguł biznesowych do zestawów danych, obsługi uwierzytelniania itp.
- Narzędzia (Util), które są po prostu biblioteką typowych metod narzędziowych, które zbudowałem w miarę upływu czasu.
- Warstwa prezentacji, którą może być oczywiście przeglądarka internetowa, stacjonarna, mobilna, cokolwiek.
Tak jest teraz
Przez ostatnie cztery lata korzystałem z platformy Entity Framework firmy Microsoft (głównie jestem programistą .NET) i stwierdzam, że posiadanie DAL staje się bardziej kłopotliwe niż czyste ze względu na fakt, że Entity Framework już wykonał zadanie, które wykonywał mój DAL: to abstrakcja działalności polegającej na uruchamianiu CRUD w bazie danych.
Tak więc zazwyczaj kończę na DAL, który ma kolekcję metod takich jak ta:
public static IQueryable<SomeObject> GetObjects(){
var db = new myDatabaseContext();
return db.SomeObjectTable;
}
Następnie w BLL ta metoda jest używana jako taka:
public static List<SomeObject> GetMyObjects(int myId){
return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}
Jest to oczywiście prosty przykład, ponieważ BLL zwykle miałoby kilka dodatkowych linii logicznych, ale wydaje się to trochę przesadne, aby utrzymać DAL w tak ograniczonym zakresie.
Czy nie byłoby lepiej po prostu porzucić DAL i po prostu napisać moje metody BLL jako takie:
public static List<SomeObject> GetMyObjects(int myId){
var db = new myDatabaseContext();
return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}
Zastanawiam się nad usunięciem DAL z przyszłych projektów z wyżej wymienionych powodów, ale zanim to zrobiłem, chciałem sondować społeczność tutaj z perspektywy czasu / foresightu / opinii, zanim przejdę do projektu i odkryję problem, którego nie zrobiłem przewidywać.
Wszelkie myśli są mile widziane.
Aktualizacja
Wydaje się, że konsensus jest taki, że osobny DAL nie jest konieczny, ale (wyciągając własne wnioski tutaj) jest dobrym pomysłem, aby uniknąć blokady dostawcy. Na przykład, jeśli mam DAL, który wyodrębnia wywołania EF, jak pokazano powyżej, jeśli kiedykolwiek przechodzę na innego dostawcę, nie muszę przepisywać mojej BLL. Tylko te podstawowe zapytania w DAL będą musiały zostać przepisane. Powiedziawszy to, trudno mi sobie wyobrazić scenariusz, w którym to się stanie. Mogę już zrobić model EF bazy danych Oracle, MSSQL jest podany, jestem prawie pewien, że MySql jest również możliwy (??), więc nie jestem pewien, czy dodatkowy kod kiedykolwiek zapewniłby opłacalny zwrot z inwestycji.
GetMyObjects(int myId)jest łatwiejsze niż kpowanie / karczowanie / fałszowanie GetObjects.Where(ob => op.accountId == myId).ToList().