This question is locked. New answers and comments are not allowed.
Most comparisons I have seen so far regards the heavy weight ORM.s but how does
OpenAccess stack up against the ultra light weight ORM:s like Dapper and, PetaPoco etc? Is the general idea that
these type of ORM.s best work with huge databases with tons of relations etc?
Thanks in advance
OpenAccess stack up against the ultra light weight ORM:s like Dapper and, PetaPoco etc? Is the general idea that
these type of ORM.s best work with huge databases with tons of relations etc?
Thanks in advance
1 Answer, 1 is accepted
0
Hello Marcus,
Conceptually you are right, as thinner the mapping layer is, as faster should the system be. On the other hand, you have to see that there are various ways to be faster then a thin mapper. OpenAccess comes with various caches, where I think we can do operations a lot faster and more secure.
Our first level cache makes sure that the data is unique per session and if the data is assessed by reference or queried more then once, you always get the same object back. Which that makes it faster if you access the same object by various references and more secure because you avoid optimistical concurrency control errors in a session. The second level cache is a shared cache below all sessions and allows you to cache single instances or complete query results. The cache is even clustered so that you can easily use it in a web farm. The second level cache is for performance only. If you execute the same query or need the same object in various sessions, the relational server is not hit at all, we find it in the cache.
A lot of mappers are working with refection to fill the objects and to store the changes. OpenAccess works different. We do not use reflection during the expensive load and store operations.
All this together makes us comparable even to slim and fast implementations. In a real application scenario OpenAccess is faster.
Regards,
Jan Blessenohl
the Telerik team
Conceptually you are right, as thinner the mapping layer is, as faster should the system be. On the other hand, you have to see that there are various ways to be faster then a thin mapper. OpenAccess comes with various caches, where I think we can do operations a lot faster and more secure.
Our first level cache makes sure that the data is unique per session and if the data is assessed by reference or queried more then once, you always get the same object back. Which that makes it faster if you access the same object by various references and more secure because you avoid optimistical concurrency control errors in a session. The second level cache is a shared cache below all sessions and allows you to cache single instances or complete query results. The cache is even clustered so that you can easily use it in a web farm. The second level cache is for performance only. If you execute the same query or need the same object in various sessions, the relational server is not hit at all, we find it in the cache.
A lot of mappers are working with refection to fill the objects and to store the changes. OpenAccess works different. We do not use reflection during the expensive load and store operations.
All this together makes us comparable even to slim and fast implementations. In a real application scenario OpenAccess is faster.
Regards,
Jan Blessenohl
the Telerik team
Follow @OpenAccessORM Twitter channel to be the first one to get the latest updates on new releases, tips and tricks and sneak peeks at our product labs!