-1

I am building a web api for my application and right now i am looking for ways to design my data access layer.

At the end, the application should be able to support a very large number of client and a very large number of queries.

I have heard about entity framework but i have two concerns with it:

  1. I have been told by many that entity framework is not the best when it comes to performance, and performance is something that i can't afford to neglect.

  2. I am only starting to build the application and i'm still looking for developers to join me, if i start with entity framework now, i might want/need to change an orm/library (because of the reason above or any other reason) or even a database technology in the future.

Repositories are a great way to abstract the data access layer and make it invisible to the business layer, so if one day i want to change the DAL/Database technology, i won't have to touch the business, only change the repositories.

Still, i have read a lot about how combining entity framework with the repository pattern is a bad practice.

I am really confused... and i have few questions.

  1. Should i use entity framework? Performances is an important thing to me.

  2. Should i combine it with repository pattern? If not, what do i do when i want to change the database technology/orm?

I have practice with using the repository pattern with native sql client (running native sql queries) but i don't have any practice with using orm's, at least not in .net

  1. Is it really a bad thing for big application to use native sql queries and wrap them with repositories?

It is really important for me to begin writing my application in best way possible (applying all the best practices) so i won't have much struggle in the future.

Thanks, Arik

areller
  • 4,800
  • 9
  • 29
  • 57

2 Answers2

0

Ad.1) Yes, Entity Framework is dead slow - BUT - when used out of the box, if the developers has deep knowledge of Entity Framework, what it does behind the scenes, how to optimize the queries - it can be as fast as your more low-lewel own implementation of data access.

Ad.2) If you want to change the ORM or the Database technology - that is not a matter whetever you use EF or not, it's a matter of the architecture you will design for the software.

Ad.1) see former Add.1, if performance is really important, I personally would go with low-level SqlDataReader, altough as I sad, it's possible to use EF in a performant way.

Ad.2) I don't see nothing bad in combining the repository pattern with EF, in small applications it may be an overhead, because the EF is basically an implementation of an repository pattern, so you would get a "double repository pattern", but it allows you to abstract away the coupling with EF

Ad.3) I don't think it's a bad way - but it depends obviously on the application.

alek kowalczyk
  • 4,896
  • 1
  • 26
  • 55
  • I see lot of code examples on the internet where the use of entity framework is tightly coupled with the business layer and i really don't want it to be that way, right now the one thing that is more important to me than performances is maintainability and flexibility. I am not familiar with entity framework and i think that getting familiar with it at the lowest level will consume too much time, so i think i'll start implementing the repository pattern with native sql queries or maybe some micro-orm (like dapper). Thank you for the useful response. – areller Aug 08 '15 at 07:51
  • 1
    Yup, those code examples are what they are - code examples. Usable at maximum for small applications. I would go exactly the same way you are suggesting. – alek kowalczyk Aug 08 '15 at 07:55
  • EF is as fast as any other ORM. Using low level methods wastes heaps of dev time. Disk and CPU are cheap – TFD Aug 08 '15 at 08:16
  • @TFD Still, does it mean that abstracting the data layer is a bad idea? I can make repository implementation that will use the entity framework and at the same time allow me make changes to the database technology at any time without touching my business layer. So what are the drawbacks of abstracting the DAL by using repositories? – areller Aug 08 '15 at 08:44
0

I think that using a repository pattern is a good idea and a sort of wayout if you have some performance issues.

About Dapper the question is why Dapper is more performant than EF and NHibernate. No Lazy Load, no DML, easy mapper and so on. If you want DML (I do) and sometimes Lazy Load you could have a mixed approach. Repository Pattern + EF + Dapper.

My approach actually is Repository Pattern + EF + very few query (massive update and delete and few select - EF writes huge SQL statements also for simple queries - ). To map the select you can include Dapper (I don't), do it by hand (manually mapping or use the features inside EF - but there are some limitations - or write something generic). Usually I map it manually but I wrote also a mapper based on EF Mapping
Entity framework Code First - configure mapping for SqlQuery
I used it for few times and actually I don't use it anymore.

Community
  • 1
  • 1
bubi
  • 6,414
  • 3
  • 28
  • 45