Question
Although EF is a very popular staff, I'm not sure how I should use it. I encountered numerous ef problems while working on various projects with various methodologies. Consequently, I started to have some questions. I utilize pure ado.net with stored procedures as a result of the responses. So, here are the inquiries:
- How should an n-tier application handle EF?
We have some DAL with EF, for instance. I came across numerous articles and projects that leveraged repository and unit-of-work patterns to abstract EF in some way. Such an approach, in my opinion, eliminates the majority of the advantages that accelerate development and results in a few things:
- Remapping the EF load causes some DTO, which destroys performance (call some select to get table data - first loop, second loop - map results to some composite type generated by ef, next - filter mapped data using linq and, at last, map it to some DTO). Remapping to DTO specifically kills one of the greatest efs benefits;
or - results in significant cohesions between the app and the EF (and its version). It will resemble a two-tier app with a dal and presentation with a bll or a dal and presentation with a bll. It probably isn't best practice. The same loading procedure was used for the preceding item, with the exception of the mapping, so a performance issue arose once more. Without any abstraction below them, we may attempt to use EF as a DAL. But we shall encounter related problems in another manner.
- Remapping the EF load causes some DTO, which destroys performance (call some select to get table data - first loop, second loop - map results to some composite type generated by ef, next - filter mapped data using linq and, at last, map it to some DTO). Remapping to DTO specifically kills one of the greatest efs benefits;
Should I just utilize one context for an atomic app-thread operation? One context per app thread may marginally improve performance and the ability to call navigation properties, however this solution also introduces the issue of updating the context when more data is loaded into it. I'm also unsure about concurrency with one dbcontext per app thread. We will need to remap ef outcomes to our DTOs as a result of using context for each operation. As a result, you can see that we returned to question number 1.
Could we try using solely EF + SPs? We are still having problems from earlier inquiries. Why use EF if the majority of its capabilities is not going to be used?
Thus, EF is a wonderful place to start a project. When we only have a few displays and basic operations, it is very convenient. Then, what?
The entire essay is basically a collection of random ideas. I am aware that using pure Ado.net will provide new difficulties. What do you think of this subject, then?
Accepted Answer
If you adhere to the naming conventions, you will learn that it is called: Entity Framework can't be faster because it is built on top of ADO.NET, although it may accomplish both tasks equally quickly. Instead, let's look at what EF offers:
- You won't have to worry about getting trapped creating queries without knowing if they would actually compile or not.
- It forces you to write your own data restrictions that you intend to accept from the target user directly inside your model classes using C# or your preferred.NET language.
Finally, EF and LINQ allow you a lot of flexibility for future application maintenance.
The Entity Framework has three different models: Model First, Database First, and Code First. Learn about each of them.
-The reason why remapping kills speed on the first run is because EF loads information into memory, which takes time as it creates an in-memory representation of the model from an edmx file.
Popular Answer
ADO.NET provides consistent access to data sources such as SQL Server and XML, and to data sources exposed through OLE DB and ODBC. Data-sharing consumer applications can use ADO.NET to connect to these data sources and retrieve, handle, and update the data that they contain.
Entity Framework 6 (EF6) is a tried and tested object-relational mapper (O/RM) for .NET with many years of feature development and stabilization. An ORM like EF has the following advantage
ORM lets developers focus on the business logic of the application thereby facilitating huge reduction in code.
It eliminates the need for repetitive SQL code and provides many benefits to development speed.
Prevents writing manual SQL queries; & many more..
- In an n-tier application, depending on how much data your application and database can handle. DTOs don't, as far as I'm aware, kill performance. They serve as data containers for passing data across levels; they do not contain any business logic. They are primarily employed in service learning courses. look at zzz-13 zzz
- A single DBContext is always recommended.
- To my knowledge, there is no such combo as EF + SP (Stored Procedure). Try using micro-ORMs like Dapper, BLToolkit, etc. if you want to utilize an ORM like EF and an SP at the same time. It was created with that goal in mind and is far faster than EF. This article on Elegant ORM. is good.
Here is a thread on a relevant subject: What makes an ORM different from ADO.net?
Related Questions
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
