Reputation: 163
In our company we have a lot of old Delphi applications and we want to rewrite them to .Net applications. These applications are very complex, because they stared with them 15 years ago and are still expanding them.
I'm the only (real) .Net developer in the team.
Now the head of the department wants to use the Entity Framework because he read something about it.
But I don't have experience with EF, but I have created my own framework, based on SQL statements.
I don't see how EF can be easier and stronger than SQL statements.
Can somebody convince me why we should move to Entity Framework? Taking into account that the team knows SQL, but are not real .Net developers.
Thanks
Upvotes: 4
Views: 229
Reputation: 13670
The head of your department seems a'ok. Invest in learning the Entity Framework, its robust, tested, functional, flexible, and best of all, you can still use your framework too. Though, I advise just using only EF. Especially if you are to pave the way for future .NET devs in the company, use EF. Its well documented, so you can jump right in less than a single day worth of coding. Furthermore, if these applications are being expanded upon todate as you say, EF will pave the way (very easily too) for things like MySQL and other connector support (after all that is one of its strengths). EF will gain you so much in the short and long term. You also get the support of the tools for EF, which is a huge ++. I used my own ADO.NET stuff for a long time, then moved to DLinq, and now EF and I will never look back (for the most part). MSFT is still making improvements to EF too (being 4.1 was just released in April), so I would have to say its a great choice. Its the core for our data layer in our new flagship product too, supporting MySQL, SQL 2005, 2008, Azure, and 2008 R2 pretty much out of the box. +++
Upvotes: 0
Reputation: 754388
If you're in the lucky position to be able to start from scratch, on a green pasture - by all means, invest that time you need to get to know Entity Framework!
It's a great ORM - and a great productivity helper. EF can help you make the 80% case - grabbing an object, manipulating it, and storing it back into the database - just sooooo much easier!
using(MyDatabaseContext ctx = new MyDatabaseContext())
{
Customer c1 = ctx.Customers.Find(4711);
c1.Name = "Acme Inc.";
// set other properties, if needed......
ctx.SaveChanges();
}
Is using your SQL based framework just as easy as this?? Can't be that hard to learn for Delphi developers! Delphi and the .NET framework are actually quite similar (duh! the same guy created them, basically.....) and coming to .NET from Delphi is very easy and very natural (I did this step couple years ago) - much easier than for an old-school VB6 developer, actually....
Go read up on Entity Framework - start with the Absolute Beginner's Guide to Entity Framework! EF takes care of just soo much silly and boring "glue code" that you don't have to write yourself anymore.......
Also: using EF doesn't mean you cannot use SQL anymore - for certain tasks, like bulk operations, SQL is still by far the best choice. If you need, at least with EF in .NET 4, you can even plug in stored procedures in places where performance or other concerns require it. Works like a charm!
Find lots of info on Entity Framework (white papers, samples, videos) at the MSDN Entity Framework Developer Center
Upvotes: 3
Reputation: 44605
Even if you have made your generic dal whic allows you to call stored procs and get tables, scalars, readers and so on I doubt that classes will be as tested and mature as the db context object of EF.
Dont forget you can use EF to call your sql stored procs or get data with sql and you do not need to model all entities at day 1.
I would rely on db context class just to write modern .net code and forget about direct managing SqlConnection and SqlCommand by hand the Ado.Net way.
Upvotes: 0