Should I stick onto Entity Framework?

Question

I adopted EF (out of box of .NET 4.5) in my new internet web app.

this app do involve quite some operation over db activities, and involve around 30 or more tables.

my point is this is not a simple school project, where EF typically suit for most needs.

as further I developing this app, I found EF very limited or prohibitive for proper/good db design (especially in term over performance)

1) Include

I encountering the Include feature in the query part. Many data missing is due to missing include setting.

the more I putting in this thing, the more I worry a simple data retrieval is getting more things than I needed in certain function.

2) Validation

I'm adopting Fluent Validation for this need, as I prefer the visitor pattern, where no direct code changes needed over the data code itself.

but then I getting more challenges as I subclassing, I need to workout validation able to respect OOP simple stuff. I managed it, though more complexity and certain things I really dislike in its implementation. I believe this subclass validation issue happened in DataAnnotation as well.

3) Transaction

Now, I need to incorporate proper db transactaction control, and I found this lacking in EF, correct me if I'm wrong.

I used to worked with Enterprise component (COM+ in .NET, long-long time ago), and I can't find the proper (or the lack of it) transaction implementation in EF.

I'm still working on this...

concluding)

I come to realize the only thing EF has helped me in my coding, is the data/entity code generation, which this is common feature over many other tool/framework.

I'm thinking to drop this EF, switch back to pre-EF era approach, adopting stored-proc, still code-generated table class (but not EF or DBML).

I can do without SQL LINQ, as I have many challenges over this in past over performance issue.

I like your opinion that I should stay and stick to EF, for whatever reason that my simple mind can perceive, apart from this ORM, which hardly is realistically working at all.

Answer 1

Have you looked into Dapper? Dapper is a micro ORM which is super fast. It was developed by Stackoverflow folks (Sam Saffron) and they use it on this site extensively for the very reasons you mention - performance and speed. Here is the link:

https://github.com/StackExchange/dapper-dot-net.

We ditched EF and we use Dapper exclusively. Combined with some other community developed Dapper extensions like Dapper.SimpleCRUD and Dapper.SimpleCRUD.ModelGenerator we can quickly generate POCOs from database while retaining all the advantages that Dapper has over EF. Overall you will be writing a bit more code but the speed of Dapper is almost equivalent to using ADO.NET's SqlDataReader. Here's a link to SimpleCRUD:

https://github.com/ericdc1/Dapper.SimpleCRUD/

Answer 2

I agree EF is less useful when you get beyond a certain stage

If your database is useful beyond your application then design the DB for your enterprise, not just your application. This is where EF falls down. It does not (cannot) consider the different viewpoints onto the database the other players in need, so you end up with naive indexes and relationships.

My 2c (quick response to a very complex question):

Write SPs (yeah, I know) to manage the data collection, provide useful data sets to your business layer and allow inserts/updates to your underlying tables. Make sure you write a useful data API though, don't just write CRUD for each table. That's a pointless waste of time.

Use EF to hook into these SPs. EF generates useful data classes, gives you a transaction wrapper and quite a few other useful bits & bobs.

Enjoy!

No one tool does everything - pick & choose as circumstances arise.