OR mapping best practice

Question

User913922097 posted

 Simple question. I have been doing OR manually or sometimes generating oo code from Sybase power designer and tweaking it.

most of the time, i would include the foreign key of a table into the definition of a class, ex class employee will have a DepartmentId property in it's definition.

This has worked so far very well, but i just feel like doing things this way is just another way of replicating the Relational database structure in OO code...

is there another way of doing things? especially when it comes to dealing with n-n relationships, which i used to create classes for as well with two foreign keys so far...

thanks,

Answer 1

User-1366948256 posted

here is the link that might help you.

http://stackoverflow.com/questions/678217/best-practices-for-mapping-dto-to-domain-object

http://stackoverflow.com/questions/481512/best-practices-3-tier-architecture-in-linq

From my experience you should only use OR mapping when its needed otherwise simple data layer will have best performance.

Answer 2

User913922097 posted

we are actually working on an enterprise platform getting data from various sources as well as web services. it will be accessible for thousands of users...we anyway do OR mapping for most of the apps we develop.

i am looking right now at the new entity framework, but i am not sure whether it is a viable solution as microsoft still doesnt provide any natively generated poco classes and objects... if my developpers are going to create classes from scratch and start dealing with LINQ to Entity to fill the objects then i don't really see the point of using EF. 

Answer 3

User-389939489 posted

> most of the time, i would include the foreign key of a table into the definition of a class, ex class employee will have a DepartmentId property in it's definition.

I am not an expert in the field of OR mappers,  my experience is not that different from yours in that respect. To your question I'd answer that a DepartmentId property is the way to go, as long as we are talking of data objects at data access layer level. You would have strongly typed references if that was a business layer class with business logic.

As to the fact that it is mostly replicating the relational structure, I'd say that's on a side inevitably true: ORMs are no holy grail, mostly efficace when they autogenerate the DAL, otherwise it's just more pain in most cases; on the other side the point of a DAL is to abstract the relational model and the details of the data source and connection, so there wouldn't be much logic in any case, just the forcing of a relational model to an in-memory object model. Not to mention the fact that, on non-trivial systems, DALs that are not really properly written and fine-tuned for the specific situation just give unacceptable performances.

My 2c,

-LV

Answer 4

User913922097 posted

makes sense, thanks Ludovico 

Answer 5

User913922097 posted

again going through EF, and it seems like deleting a record requires having that record in the first place as an instanciated object, which means that the object has to be fetched in the first place! is this how it is right now? imagine retrieving large binary data objects just to be able to delete that particular record.

Answer 6

User-952121411 posted

microsoft still doesnt provide any natively generated poco classes and objects...

 

I might not be interpreting this correctly, but in the Entity Framework 4.0 there is POCO support:

POCO in the Entity Framework: Part 1:

http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

Working with POCO Entities (Entity Framework):

http://msdn.microsoft.com/en-us/library/dd456853.aspx

 

Answer 7

User913922097 posted

3.5 framework here, VS2008

don't feel like switching to 4.0 just to get poco support. probably better off using traditional approach (Stored Procedures/DAL + BLL + POCO)