June 27, 2015 at 23:05Entity Framework or why I implement Repository
Abstraction? Who needs abstractions?
EF is the coolest ORM from MS. habrahabr.ru/post/157267 it's really cool. To develop such a system is very expensive in all directions. CodeFirs thing, knowledge of database design, but what a thing! You don’t need the knowledge of SQL itself - and this is cool. But is everything so rosy?
Julie Lerman can tell a lot msdn.microsoft.com/en-us/magazine/ff898427.aspx
Doesn't it remind you of anything?
This is an implementation of Repository + UoW. So, is it useless to make all kinds of wrappers when using EF?
EF is insanely popular technology, it is difficult to find the right provider for your storage.
The main idea of EF (like any Repository) is to separate the subject layer from the storage layer. But why?
Everything is simple - so that without painfully changing the storage and the item, it is independent.
I would like it to never, but as they say "never say ..". I am working on a project in which there are two combat layers of storage and another demo. The client himself chooses how he will store his data.
The answer lies in the compatibility of specific providers. Here's what compatibility is said by one of the developers of such providers, Yevhen Shchyholyev www.infoq.com/articles/multiple-databases . Problems that were understandable on an intuitive level are reinforced by the developers themselves.
Here is some of them
Types are an eternal problem. That is, one script executed on one provider (namely on the provider) may not give the same results on another.
The problem that arose with us was that the date was stored in UTC, but EF under SQLight persistently returned to Local. The problem was easily solved, because we use Mapping.
Here the most interesting thing, for different providers you need to write your own LINQ queries. Another interesting scenario: they wrote some functionality with a bunch of queries to the context and everything works fine. But the application is cross and you need to check how this will work on another provider. It was found that some of the queries became ineffective. It doesn’t matter - optimization. All is well. The question is how the optimization affected the work with the original provider?
It clearly says mission impossible . SQL SQL is different, provider to provider. This is not even about the fact that the request will not be effective, but about the fact that it can ruin the execution of the application.
Here is the link . But not just anyone, but a leading developer of a set of third-party providers says mission impossible .
That is, these are not all the problems that can arise beyond those described, and which can only be learned by standing on the rake.
EF is a good abstraction, and like any abstraction, it is not without its main drawback - its implementation. The problems described in this article are not taken from the head and not from the lips of skeptics, but from the first hand - the provider of providers.
Providers are developed by different companies, and I am sure that if you use providers from different manufacturers in one project, there will be much more compatibility problems. forums.mysql.com/read.php?174 , 614148,614148
I in no way say NO EF , I say Yes Repository, because all the problems described are easy to get around with this abstraction which will wrap EF and absorb compatibility issues.
Only a technological example is considered, for which it may be necessary to implement a “Bicycle”, the reasons for which you can and should use a repository and lotions are much more.
EF is the coolest ORM from MS. habrahabr.ru/post/157267 it's really cool. To develop such a system is very expensive in all directions. CodeFirs thing, knowledge of database design, but what a thing! You don’t need the knowledge of SQL itself - and this is cool. But is everything so rosy?
Julie Lerman can tell a lot msdn.microsoft.com/en-us/magazine/ff898427.aspx
Doesn't it remind you of anything?
This is an implementation of Repository + UoW. So, is it useless to make all kinds of wrappers when using EF?
EF is insanely popular technology, it is difficult to find the right provider for your storage.
The main idea of EF (like any Repository) is to separate the subject layer from the storage layer. But why?
Everything is simple - so that without painfully changing the storage and the item, it is independent.
When do i need to change storage?
I would like it to never, but as they say "never say ..". I am working on a project in which there are two combat layers of storage and another demo. The client himself chooses how he will store his data.
Is it necessary to build abstraction on top of abstraction and do what has already been implemented?
The answer lies in the compatibility of specific providers. Here's what compatibility is said by one of the developers of such providers, Yevhen Shchyholyev www.infoq.com/articles/multiple-databases . Problems that were understandable on an intuitive level are reinforced by the developers themselves.
Here is some of them
Data types
Entity Framework supports a limited set of .NET types (signed integers, Single, Double, Decimal, String, Byte [], TimeSpan, DateTime, DateTimeOffset, Boolean, Guid). However, not all .NET types from this list are supported by databases.
Types are an eternal problem. That is, one script executed on one provider (namely on the provider) may not give the same results on another.
DateTimeOffset Support
DataTimeOffset is the most problematic .NET type. It is supported in SQL Server MS 2008, Oracle, and SQLite, but not in SQL Server MS 2005, MySQL, or PostgreSQL, as these databases do not have a DateTime that can preserve the time zone offset.
The problem that arose with us was that the date was stored in UTC, but EF under SQLight persistently returned to Local. The problem was easily solved, because we use Mapping.
Performance
If the specific features of a particular database are not taken into account, it is possible that a LINQ query can be processed faster in one database and slower in another.
Pagination of data performed by LINQ methods .Skip () /. Take () can be one of the most expensive operations. Unlike in SQL Server, Skip / Take, Oracle generates two subqueries with sorting in the internal subquery, which can adversely affect performance. It should be noted that pagination can be quite inefficient in other databases, especially if the sorting is performed by non-indexable columns.
Here the most interesting thing, for different providers you need to write your own LINQ queries. Another interesting scenario: they wrote some functionality with a bunch of queries to the context and everything works fine. But the application is cross and you need to check how this will work on another provider. It was found that some of the queries became ineffective. It doesn’t matter - optimization. All is well. The question is how the optimization affected the work with the original provider?
Request Limitations
In EF, a developer can formulate queries using either LINQ to Entities or Entity SQL, or a combination of both. In any case, such a query is converted by the EF engine to an intermediate representation as an expression tree and sent to the EF provider to generate an SQL query. Since EF was originally developed for SQL Server, sometimes EF providers must significantly transform the original expression tree in order to generate the correct SQL for a specific database. However, this is not always possible .
It clearly says mission impossible . SQL SQL is different, provider to provider. This is not even about the fact that the request will not be effective, but about the fact that it can ruin the execution of the application.
The relevant MSDN section says that all these functions are supported by all EF providers:
"This section discusses the canonical functions that are supported by all data providers and can be used by all query technologies."
This section seems to be over-optimistic, since different DBMS have different functionality, and sometimes it is not possible to realize all the possibilities for compatibility.
Here is the link . But not just anyone, but a leading developer of a set of third-party providers says mission impossible .
Conclusion
In this article, I tried to provide a brief description of the most common problems during the development of EF applications for non-Microsoft SQL Server databases. Undoubtedly, many other aspects have not received attention in this article ...
That is, these are not all the problems that can arise beyond those described, and which can only be learned by standing on the rake.
To summarize.
EF is a good abstraction, and like any abstraction, it is not without its main drawback - its implementation. The problems described in this article are not taken from the head and not from the lips of skeptics, but from the first hand - the provider of providers.
Providers are developed by different companies, and I am sure that if you use providers from different manufacturers in one project, there will be much more compatibility problems. forums.mysql.com/read.php?174 , 614148,614148
I in no way say NO EF , I say Yes Repository, because all the problems described are easy to get around with this abstraction which will wrap EF and absorb compatibility issues.
PS
Only a technological example is considered, for which it may be necessary to implement a “Bicycle”, the reasons for which you can and should use a repository and lotions are much more.
