Entity Framework or SQL

We have a lot of old Delphi applications in our company, and we want to rewrite them to .Net applications. These applications are very complex because they looked with them 15 years ago and are still expanding them.

I am the only (real) .Net developer on the team.

Now the department head wants to use the Entity Framework because he read something about it.

But I have no experience with EF, but I created my own framework based on SQL statements.

I do not see how EF can be simpler and stronger than SQL queries.

Can someone convince me why we should go to Entity Framework? Whereas the team knows SQL, but they are not real .Net developers.

thanks

+4
source share
3 answers

If you are in a happy position to start from scratch, on a green pasture - by all means, spend the time you need to get to know the Entity Framework!

This is a great ORM - and a great performance assistant. EF can help you do the 80% case - capturing an object, manipulating it and saving it back to the database is just that simple!

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 database as easy as that? It can't be that hard to master for Delphi developers! Delphi and the .NET Framework are actually very similar (duh !, the same guy created them, mostly .....), and switching to .NET from Delphi is very simple and very natural (I took this step a couple of years ago) - much easier than for the developer of the old VB6 actually ....

Go read in the Entity Framework - start with the Absolute Entity Framework Beginner's Guide ! EF only cares that there are too many stupid and boring “glue codes” that you don’t need to write anymore ........

Also: using EF does not mean that you can no longer use SQL - for certain tasks, such as bulk operations, SQL is still the best choice. If you need to, at least with EF in .NET 4, you can even attach stored procedures where it requires performance or other problems. It works like a charm!

Find a lot of information about the Entity Framework (white papers, examples, videos) at the MSDN Entity Framework Developer Center

+3
source

Even if you made your general dal whic, which allows you to call stored procs and get tables, scalars, readers, etc. I doubt the classes will be as tested and mature as the db context object for EF.

Do not forget that you can use EF to call your sql-stored processes or retrieve data using sql, and you do not need to model all entities on the first day.

I would rely on the db context class to write modern .net code and forget about directly managing SqlConnection and SqlCommand manually using Ado.Net.

0
source

The head of your department seems a'ok. Invest in exploring the Entity Framework, its reliable, proven, functional, flexible, and most importantly, you can still use your infrastructure. Although, I advise you to just use only EF. Especially if you want to pave the way for future .NET developers in your company, use EF. It is well documented, so you can jump right in one day when you need to code. Also, if these applications expand after todate, as you say, EF will pave the way (very easy) for things like MySQL and support for other connectors (after all, this is one of its strengths). EF will bring you so much in the short and long term. You also get tool support for EF, which is huge ++. I used my own ADO.NET stuff for a long time, then switched to DLinq, and now EF and I never look back (for the most part). MSFT is still making improvements in EF too (4.1 was only released in April), so I have to say that this is a great choice. This is the core for our data layer in our new flagship product, which also supports MySQL, SQL 2005, 2008, Azure and 2008 R2 pretty much out of the box. +++

0
source

All Articles