We been having some discussions on approaches to using the entity framework at work recently. We have a fairly large and complex n-tier web based application, which is due for a major overhaul.
The question is: If we where to starting using the entity framework, would it be better to create one big model, or a set of smaller functional/acivity based models.
I have my own opinions on this, but would be interested to hear what some other people think.
Update (17th November 2008):
I have been creating one model, wiping it out and re-creating, etc for small projects at home. Although I haven't tried, I suspect that this approach will be a bit more challenging when there are a large number of entity types involved.
Also, does anyone have any experience of using ef with a large team using TFS or similar?
In my experience with it, I would just make one big model of the database. Otherwise, it might be hard to track what tables changed where. When I make changes to the database, I just delete all the tables in the model and regenerate it.
Of course, I also didn't customize my model by adding "entity" functionality to it (not sure how that works exactly).
So I'm no expert in it, but I usually end up using the LINQ-To-SQL models/objects instead of the Entity Framework - it's worked better for me so far.
Related
I am stating a new project that needs to be portable and in some scenarios will have 100's millions of entities.
Now with Azure getting hadoop that of course got my attention for the big data scenario. But I also have the small data scenario under 1 million rows.
Entity Framework code-first is they way I see designing this but needing hadoop in the mix of course may complicate things (Entity Framework of course been used to give simpler storage providers for the smaller data sets)
Now the question is does anyone have experience in this mix?
Can anyone recommended if this is a good approach or not, if not is there a better way?
Working on a reasonably large system based on Entity Framework Code First, with the caveats that I have been working with EF4 and cannot upgrade to 5, that your mileage may vary and the outcomes are going to be strongly affected by what you intend to do, my experience has been that EF doesn't handle large amounts of data tremendously well, it is quite inflexible, so if you need to change its standard behaviour in some way there is a good chance you are going to end up having to hack some nasty workarounds, and performance isn't amazing. If you want to do things that aren't exactly the things that EF expects you to do, then you can run into walls.
If I was thinking of designing a relatively simple/small scale Asp.Net MVC setup, I think EF is a really good choice. For a larger scale operation where you need more flexibility or you are planning to go beyond basic operations you might find that something like NHibernate works better. I don't have experience with that, but colleagues who have worked with both tend to prefer NHibernate. ( Brief article on the comparison - a bit old so EF has addressed some, but not all of the points there. It is also different by design of course. )
It may be that for more high-traffic or unusual stuff you need to roll your own data access anyway just to achieve the right performance or be able to find the right data. Unsquestionably, if you are planning to try working with EF I strongly recommend some serious prototyping just to ensure it can do what you need.
I'm starting a new project and I'm interested in using Entity Framework. However, since this is a new project, there isn't an existing model or database yet, so I could either use database-first or model-first in this situation.
When starting with a blank slate like this, is it recommended to use model-first and let EF determine the database design or design the database yourself? I'm comfortable designing normalized databases so I'm not afraid of that aspect, but I'm not sure if there are maintainability and performance benefits from letting EF handle all the database design.
Thanks in advance guys!
In a green field project my choice would be code first, or possibly model first. As your project progresses over time you should only be dealing with code and have EF manage database schema changes for you. Using other approaches can lead to moving focus from core activities to model maintenance. On a project I worked on we were coerced by management to use a database created by a dedicated schema developer who only knew how to use SQL Server Management Studio. Therefore every change in database meant we had to regenerate code. This eventually caused us to spend 2 days to develop tooling for automatic importing of DB schema and generation of object model (this was in EF 3.5 days).
I'd leave database first approach for brown field and maintenance projects.
Check out: link1 and link2, then decide it's up to you
Well, as a developer, comfortable with any old way to build databases, I've found that code first lets me concentrate on my task. Your mileage may vary.
I've used it many time and have been able to maintain my databases using code first style without difficulty.
We are considering moving from Entity Framework to PLINQO L2S. EF has proven to be quite difficult for us to manage in an MVC3 application. I would agree there are areas of our application that can be improved, but overall, EF may not have been the best choice for us.
I am curious to know, recently, if anyone has moved form EF to PLINQO L2S? I have read many posts from back in 2010, but EF was a much different animal then. i am not interested in PLINQO for EF.
We ended up evaluating PLINQO and found there were bugs trying to emulate our model generated by Entity Framework. It was not an issue with how EF generated the database, but rather an issue with PLINQO appending numbers to collection entities. There was too much clean up for us to consider using PLINQO. It has some great features, but the generation caused us issues
We removed our DTO layer and decided to go with pure entities. The performance increase was huge. We tried several mapping libraries and even created our own direct mapping solution, but the cost in performance was too great.
EF 4.1 CodeFirst looks great. It works and sells wonderfuly with basic examples that have one or two joins, but what about larger applications? Did anybody work on a large application where domain and data access layers were implemented with EF 4.1 code first? Did it work? Was it as easy and smooth as examples on asp.net site? I'm mainly working on MVC applications, where there is no change tracking. So far I have been using LINQ-to-SQL, which worked well with some extra mapping code.
Thank you
I'm in the later stages of developing a web application that is fairly complex with EF 4.1 CodeFirst (well its more complex than most examples). I don't pretend to be an expert on code first so others may have different opinions.
I used a domain driven approach along with the repository pattern. The database created by code first worked well though I had to manually optimize the database and add indexes etc. Did have an issue bolting on mvc-profiler but nothing drastic.
There was a learning curve but I reckon that was more down to my lack of knowledge about code-first than anything intrinsically difficult about it. When we started developing the app the ability to recreate a db and seed it sped things up at the start. Though we have disabled that now and any db changes are made manually and the code is updated.
So for me code first worked well, I like this approach for new applications and it wasnt too difficult to get up and running (lots of reading up).
I was surprised to find a public letter proposing a vote of no confidence in the entity framework (see http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/)
Would the reasons stated in the letter keep you from using the current version of the entity framework? Would you rather wait for v4.0? Or rather use another ORM?
The current version of EF is definitely not perfect, and has lots of gotchas and drawbacks. I probably wouldn't use it right now - but the upgrade path to EF v2 (or is it EF4?) sure looks pretty rosy!
complete persistence ignorance - you can use your straight up POCO classes
deferred loading configurable as an option
much improved designer with support for pluralization/singularization (even in multiple languages!)
ability to do "domain first" design and create database from your model
ability to have self-tracking entities across multiple layers that allow you to send data to the client and get back changes and apply them to your entity context
All in all, EF v2 looks very promising and I'm very eager to give it a serious spin. If it really keeps all the promises out there right now, it's definitely a winner!
Check out the ADO.NET team blog for a flurry of recent blog posts on EF v2.
Marc
Another ORM.
Don't get me wrong you should get flamed with responses, but currently only nHibernate is functionally complete.
I'm a TDD fan, so want an easily testable POCO ORM solution. If that's your bag then EF3.5 is out. EF4.0 is introducing it (http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx) , but it still has at least 1 big drawback -> doesn't support inheritance.
NHibernate is more complete, but EF could be easier to use. As ever, best tool for the job... but if it's an Enterprise-scale TDD developed app, go nHibernate.
Also -> there's a profiler that makes nHibernate dev much easier -> http://www.nhprof.com/
I tried using it for my current project, which basically involves rewriting our current mess of a data layer.
It just doesn't work.
First, if you're trying to base an Entity off of a View, the designer tries to force every NOT NULL property to be an entity key... which is pretty much never what I wanted. To work around that you have to edit the xml in at least two places, and do it every time you add an object because it refreshes and re-adds the EntityKey properties. Must specify mapping for all key properties in Entity Framework?
Second, when you are creating associations you MUST use every entity key - How can you make an association without using all entity keys in entity framework?
Those two things held me up for 3 days, then I went back to Linq to SQL and had it done in a couple hours. (Well, at least the part of the system I was struggling with... ) I don't know if those are in the Vote of No Confidence, but it's just not ready in my opinion.
Also with the lack of answers I got here on every EF question I've asked, I have to assume current usage is so low that getting help and support is going to be difficult... which is possibly the BIGGEST reason not to use something.
Let's hope the next version is better...
EDIT: OUr current plan is to stick with Linq 2 SQL (I have to finish a project by Friday) and then evaluate all the other ORMs to see if anything else is better. The other developer hates L2S for the record, but I've never had any major problems using it...
EF has some rich design time support, but I have to agree that nHibernate is the way to go, despite the learning curve. If you need to make something fast and don't care about TDD or serialization (which is a large weakness of all of MS's ORM offerings) go EF.
Well My experience of Version 1 was interesting. I wanted to use POCOs but it didn't support it. After reading around I came across some code from a bod at microsoft that did this.
It was a bit messy to generate the code but on the whole this part of the process was not so bad.
A real nasty part that I came across was the lack of Concurrency checking built in, for N-tier development. You have to manage this yourself which after looking at the problem was not so bad, especially if you want to hand back the versioning back to the client for user intervention.
Second nasty and absolutely stupid thing missing was the IN keyword for LINQ queries. Not supported and so needs to be worked around. I found a solution but was a real mess bringing in some other code that quickly patched up the omissions.
Would I use EF 4.0 (2.0). Yes, absolutely, why not? In fact on stage 2 I will be using this. It looks like it supports POCOs, it looks like my concurrency model will move straight across with no problems (basically delta copy stuff). Its all good so far and I hope this time round that the Big guys at Microsoft have seen the errors of their ways and provided a solution that works.
If your buying into entity development and the whole Concept Model first thing, then its the only way to go for a complete Microsoft solution. Although the stuff being done on the M language might eclipse the idea and move the whole modelling thing back to the Database.
If you not buying into the Entity stuff then I would strongly go Enterprise Library. Its a proven technology that works every time built on a solid code foundation and Database centric paradigm. I would also go this route if you think that Stored Procedures are the bees knees and like what they bring to the table.
If your feeling really exotic and feel a bit frisky I would go with a NO-SQL approach such as CouchDB. This however does take some getting used to. Its damn weird and feels really really wrong. But things get developed in super quick time and the solutions seem to be robust and faster than expected. I would not got for this type of solution though if your big into Normalization and think that it can be applied to a NO-SQL approach. The whole model needs to be shifted on its head and the application will be needed to be modelled in a way that is driven by the technology applied.
I find the CouchDB way a bit dirty and very very wrong. But it has so many compelling reasons to use it, that I think it will seep into the psyche of every programmer, and it will definitely go mainstream in the next couple of years.
My biggest gripe still with the whole Entity thing though even in the new version 4 is that there really has not been much thought into N-tier environments. It still got a feel about it being a 2 tier solution with a lot of boiler plate code still needed to be done by the end user (developer), to get it working in a robust and dependable N-Tier way.