Hi
Is Entity Framework worth moving to for a new small app? About 10 tables and a WinForms app.
ie the alternative being DataTables/DataRows or Linq-to-SQL
can I ask why you recommend steering clear of DataTables?
Greg
2010-04-28 04:44:06
Working with datatables is very ugly. L2S and EF are much cleaner.
Raj Kaimal
2010-04-28 12:25:42
+3
A:
Entity Framework is a great product - but it's clearly designed for more advanced, more complex cases, where you need to be able to have a domain object model that is or can be different from your underlying storage model. If you need that - great - but for most smaller apps, this is total overkill and only adds additional layers of performance killers.
For a small app, go with Linq-to-SQL - or have a look at Subsonic. Those both offer quite thin and very simple layers on top of your tables, and they work great for smaller apps.
DataTables are so 1990's .... stay away, they're messy, they're hard to use, they're not pleasant and not efficient to work with.
marc_s
2010-04-28 05:18:36
+3
A:
I'm going to disagree with those who say that LINQ to SQL is preferable for a small project, based on real-world experience using both LINQ to SQL and the Entity Framework for small projects. I have a really hard time getting over LINQ to SQL's incredibly weak schema update scenario (throw away your old model, re-generate a new one, and re-apply your customizations). You can do what you need to do with both tools, for the most part, but if your DB schema will ever change or evolve you'll spend way too much time fiddling with the L2S designer.
The best reason to avoid the Entity Framework is if you don't understand it. I'm not being flip here; if you do understand L2S and you don't understand the EF, then by all means use L2S; you will probably be more productive. But if you understand both tools, the EF can do nearly everything that L2S can do and much, much more (easy model updates, model-first, code-first models, customizable codegen, RIA services, etc., etc...).
Craig Stuntz
2010-04-28 13:17:52
thanks Craig - can I ask in your view re EF (a) is it solid, i.e. no gotchas/teething problem?, (b) if using VS2010 with EF do I ever have to jump out into XML configuration to make things happen? i.e. re level of usability, (c) roughly how is a schema change handled by a developer in EF, like how would it affect rework on the code side, (d) does it inherently decouple your business logic from data access layer as people talk about re patterns?
Greg
2010-04-28 21:00:04
(a) The EF is rock-solid from a quality POV. Its "teething problems" tend to be missing features (fewer of those in EF 4, though); the features which are there tend to work. (b) *If* you use EDMX (not required in EF 4 if you use code-first) then yes, sooner or later you'll need to edit the XML. Not often, but you shouldn't be afraid of it when you need to do it. (c) When you update, the EF regenerates your store schema and preserves client schema. No code changes unless the schema change makes that necessary. (d) No, this is *never* automatic. Developers have to practice this discipline.
Craig Stuntz
2010-04-28 21:19:44