ADO.NET Entity Framework custom classes, the right choice?

Question

I have an upcoming requirement, and I'm unsure if EF is the right approach.

Essentially I have a Web Service Contract to implement, that has a handful of methods that return specific classes (DataContract classes with DataMember'd properties so they serialize correctly). The data that makes up the classes will be the result of queries against a backend database.

At the lowest level, I know I can just write some stored procs in the database that will return data rows that I can manually wire up to the custom classes, and call the stored procs from within a Data Layer class (calls stored procs, returns custom classes).

I'm wondering if I can use ADO.NET Entity Framework for this, however my understanding that this creates Entity classes from the database tables. My custom classes don't resemble any of the database tables. The stored procs perform aggregations and table joins to produce the classes.

Am I missing something here from what's possible with the EF? Or would I be better just going with stored procs / manually wiring up the custom classes in a data layer?

The Web Service will be hosted in SharePoint 2010 therefore I'm limited to ASP.NET 3.5. I think I'd be using Patterns and Practices to access the data layer, unless there are better ideas out there.

score 3 · Accepted Answer · edited May 23 '17 at 11:56

3

Given that you have indicated that you can only use .NET 3.5, you would be using EF 1.x which wasn't widely accepted in the ORM community. EF 4.x is much improved, but unfortunately requires .NET 4.

DAAB is certainly an alternative, but you will still need to map out your Service entities from the data (i.e. DAAB isn't an ORM)

IMO EF comes into its own when used with LINQ, especially when used with queries - if you find that you are writing many SPROCs of the form GetXXXByYYY (or using lots of ad hoc or dynamic sp_executesql) to populate your entities, then a LINQ enabled ORM makes a lot of sense. However, if you only have a few heavy hitting PROCs which have well defined interfaces, then an ORM may be overkill.

edited May 23 '17 at 11:56

Community

1
1

answered Feb 06 '12 at 13:39

StuartLC

104,537
17
209
285

This particular project only has 6 methods currently. It may grow in future but not by much. Each will have a corresponding stored proc that will literally join maybe a dozen tables, do a little aggregation and spit back the rows. Looks like ORM is indeed overkill for something of this scale. Thanks for clarifying! – James Love Feb 06 '12 at 13:48
Once you are up and running with .NET 4, it is definitely worth getting your hands on EF 4.1+ – StuartLC Feb 06 '12 at 13:50
Cheers, will keep that in mind. I'm primarily a SharePoint dev, so I'll have to wait to vNext before I get the goodness .NET 4 brings. – James Love Feb 06 '12 at 13:57

score 2 · Answer 2 · answered Feb 06 '12 at 13:52

If the object model of your application remarkably differs from the data model in your database then I'd stick to the classic ADO.Net + stored procedures for aggregations and table joins. My opinion is that any ORM brings more trouble than benefit in such case.

ADO.NET Entity Framework custom classes, the right choice?

2 Answers2