Patrzyłem na tak zwane „Micro ORM”, takie jak Dapper, i (w mniejszym stopniu, ponieważ opiera się na .NET 4.0) Ogromne, ponieważ mogą być łatwiejsze do wdrożenia w pracy niż w pełni ORM od czasu naszego obecnego systemu jest wysoce zależny od procedur przechowywanych i wymagałby znacznego refaktoryzacji do pracy z ORM, takim jak NHibernate lub EF. Jaka jest korzyść z używania jednego z nich w pełni funkcjonalnego ORM? Wydaje się, że jest to tylko cienka warstwa wokół połączenia z bazą danych, która wciąż zmusza cię do pisania surowego SQL - być może się mylę, ale zawsze mówiono mi, że powodem ORM jest przede wszystkim to, że nie musiałeś pisać SQL, to może być generowany automatycznie; szczególnie w przypadku łączenia wielu tabel i mapowania relacji między tabelami, co jest uciążliwe w czystym SQL, ale jest trywialne w przypadku ORM.
Na przykład patrząc na przykład Dappera:
var connection = new SqlConnection(); // setup here...
var person = connection.Query<Person>("select * from people where PersonId = @personId", new { PersonId = 42 });
Jak to się różni od korzystania ze sterowanej warstwy danych ADO.NET, z tym wyjątkiem, że nie musisz pisać polecenia, ustawiać parametrów i przypuszczam, że odwzorowałem obiekt z powrotem za pomocą Konstruktora. Wygląda na to, że można nawet użyć wywołania procedury składowanej jako ciągu SQL.
Czy są inne namacalne korzyści, których mi brakuje w przypadku, gdy zastosowanie Micro ORM ma sens? Naprawdę nie rozumiem, w jaki sposób oszczędza cokolwiek na „starym” sposobie korzystania z ADO.NET, może poza kilkoma liniami kodu - wciąż musisz napisać, aby dowiedzieć się, jaki SQL musisz wykonać (który może stać się włochaty) i nadal musisz mapować relacje między tabelami (część, w której najbardziej pomagają ORM ORHO).
var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });a następnie dog.First().Agema dostęp do właściwości.