Tworzyłem więc warstwę dostępu do danych za pośrednictwem TDD i podniosłem nieco problem. Wolę nie zaczynać złą drogą, więc pomyślałem, że poproszę was, abyście sprawdzili, czy moje myśli są zgodne z czystą architekturą.
Metody w mojej warstwie dostępu do danych (w skrócie DAL) są dość proste. Są one zgodne z procedurami przechowywanymi w bazie danych (nie ma innego sposobu na wywołanie go w celu zachowania czystości) i zawierają te same parametry, co procedury. Następnie łączą się z bazą danych i zwracają wynik zapytania. Oto jeden przykład:
public int DeleteRecord(int recordId)
{
recordId.RequireThat("recordId").NotZeroOrLess();
List<SqlParameter> parameters = new List<SqlParameter>();
parameters.Add(new SqlParameter { ParameterName = "@RecordId", SqlDbType = SqlDbType.Int, Direction = ParameterDirection.Input, Value = recordId});
return this.ExecuteNonQuery("DeleteRecord", parameters.ToArray());
}Działa to doskonale dla tego typu metody, ponieważ nie robię nic znaczącego z zestawem wyników. Chcę tylko upewnić się, że polecenie zadziałało, więc zwrócę wynik braku zapytania, który dotyczy tylko wierszy, i mogę zweryfikować logikę przy użyciu tej liczby.
Powiedzmy jednak, że w innej metodzie DAL chcę załadować rekord. Moja procedura ładowania będzie wykonywana selectsdla wielu tabel i zwraca a DataSet, ale walczę z tym, czy mój DAL powinien tworzyć obiekty biznesowe w ramach metody przy użyciu DataSet, czy też same moje obiekty biznesowe powinny mieć po prostu Load()metodę, która pobiera DataSetz DAL, a następnie w zasadzie się wypełnia.
Wykonanie tego za pośrednictwem DAL spowodowałoby mniej logiki w obiektach biznesowych (nawet jeśli jest to tylko logika wybierania, to wciąż jest logika), ale zepchnęłoby trochę DAL i sprawiałoby wrażenie, jakby naprawdę robił coś, czego nie powinien robię.
Co myślicie?