Comments on: Why you should not use the ADO.NET Entity Framework

By: Vern

Vern — Fri, 05 Mar 2010 23:32:10 +0000

“It is not possible to define the business-entities in a separate assembly. Thus the presentation layer such as a web-application, will need to reference the data-access layer in order to get access to the business entities.

Please give understanding of above sentence in detail”

I believe what he is referring to, is the fact that the enties and the model, which provides the context itself, are both integrated. You cannot give someone access to your entities without giving them the neccessary tools to create methods to interact with your database through the entties. However, I feel this is a non concern as you still have to have access to the database to utilize the db connection. Unless they know the connection string and passwords for you database, it’s a secure, though it feels like giving out too much info. This is more of a concern for web apps. Deconstructed it can give an understanding of your underlying schema to a sql injection attacker. At least, that is my humble take on the deal.

By: Vern

Vern — Fri, 05 Mar 2010 23:26:59 +0000

Stored procedures are supported, they just have to be accessed in a non standard way. I know for a fact you can call a stored procedure without a return result. The handling looks more like ADO, but it still using EF and it’s connection info. The details can be found here:

http://dontteasetheslowkid.blogspot.com/2010/03/enitity-framew-can-support-stored.html

I’d assume you could use the DBCommand to execute queries with non entity return values and map them in custom objects as well.

By: Devaang

Devaang — Wed, 09 Dec 2009 10:22:22 +0000

It is not possible to define the business-entities in a separate assembly. Thus the presentation layer such as a web-application, will need to reference the data-access layer in order to get access to the business entities.

Please give understanding of above sentence in detail

By: Pratixa

Pratixa — Wed, 09 Dec 2009 10:21:35 +0000

Can you explain the meaning of above sentence in detail.

By: ChrisW

ChrisW — Tue, 09 Jun 2009 12:35:57 +0000

@Lars-Erik Kindblad:
I disagree with the post you made earlier on the harms of linq to sql.

You said:
“1. The entire codebase will be dependent on LINQ to SQL. If it one day doesn’t cover your needs, you either rewrite all the code or add a 2nd set of data-access code (=messy).”

If you practice proper seperation of concerns and abstract away your data access layer, then the only thing that knows about its details is the data access layer itself. Allowing Data Access code to leak into other layers is bad practice regardless of the method you choose.

“2. LINQ to SQL doesn’t handle normalized databases very well, so either denormalize or try to get around it using stored procedures or views.”

I will give you this one, support _could_ be much better for relationships.

“3. Total dependency on the designer and it’s designer generated code.”

this is just 100% wrong. You can do everything the designer does using attributes an inheritance. I never trust MSFT generated code….

“4. Finding solutions to all the limitations is really time consuming and frustrating, and a big expense in the long run.”

I just gave you solutions to the “limitations” you listed in about 30 seconds. You’re welcome.

“A good ORM should not affect anything in your codebase but the data-access layer.”

I wholeheartedly agree with this statement, and if you code it correctly, then it is easy to isolate Linq To Sql into a data access island that can be swapped in and out of your application at will.

By: Tom

Tom — Mon, 01 Jun 2009 17:53:47 +0000

I gave EF a shot and tried it out during the construction of a fairly large project. I got around some of some of the annoying anti-layered stuff by using a T4 template to auto generate decoupled POCO partial classes and everything was going fine as I was prototyping. However, I had made the assumption that LINQ and EF got along. When I finally got around to turning the crank and executing, I discovered that an absurd number of interface implimenting members of Entity simply resulted in ‘implimentation not supported’ exceptions. I couldn’t even check to see if an Entity collection ‘contains’ an Entity. What is the point of a bunch of of objects representing your data when you can’t even properly query these objects with .NET’s language integrated query? Linq to Entity is a trainwreck. Between EF and Datasets, I’m in favor of voting the ADO.NET team off of the island; these guys make the rest of the .NET teams look bad by way of association.

By: Jaime Bula

Jaime Bula — Sun, 15 Mar 2009 22:25:25 +0000

I’ve tried it on a mayor proyect and:

It makes some things faster to code, other things like Updating are insanely complicated. Bugs are unning free everywhere. Don’t get me started with the data services, it’s almost imposible to delete data with that.

Performance is crummy with big models, and when used with WCF objects can get big when transmitted.

Stored procedure support is a mess.

You will end with at least Two Data Tiers in you project.

PS: Silverligt is awesome.

By: car jacks

car jacks — Sat, 14 Mar 2009 12:16:09 +0000

I must say, that I can not agree with you in 100%, but it’s just my opinion, which could be very wrong.
p.s. You have an awesome template . Where did you find it?

By: Yuriy

Yuriy — Wed, 04 Feb 2009 19:57:42 +0000

I blogged stored proc usage here http://ygizhitsa.spaces.live.com/blog/cns!8A7B4991A271531A!203.entry

By: Lars-Erik Kindblad

Lars-Erik Kindblad — Sat, 24 Jan 2009 20:15:41 +0000

amrelgarhy:
If you read the comments on the post you referred to, you will see that stored procedures only works if they return an entity type. If they return nothing or any of the .NET primitive types, then for some reason the stored procedures wont be available through the entity context.