views:

39

answers:

3

...What is it called?

More elaborate: For my application I created a nice business model to work with as in-memory objects. It's storage and view agnostic. Now, for the storage layer, there's a database: I'll construct SQL queries (the fewer the better) that selects/joins etc. all data I need from the relevant tables. A kind of "middle layer" takes the query(s) result and constructs business objects with all relations.

Questions: What do you call this approach? What are the best practices?

This takes place in a .NET C# project but that's not relevant to this design question.

(I found question 441532 to be very similar but I'm interested in more design input)

Note: I do not take the ORM approach that relies on tools that do this automatically because the application requires only selected data from a relatively large database.

+1  A: 

I think it's called ORM, or object-relational mapping.

NHibernate is one example of just such a thing.

duffymo
No, I'm not building a 1:1 database layer (one table one class). I want to directly build up my business objects from the rows I get from a few (joining) SQL queries. I skip the ORM approach altogether.
Kay Zed
If you have data in a database and would like to use it inside domain objects, you ARE doing ORM. Be it called row data gateway, table data gateway, active record, data mapper, DAO etc.
Flavius Stef
ORM does not mean one table per class. And I think you have it backwards: You either generate the objects from an existing schema or create a domain model followed by tables. Creating arbitrary objects from any query you decide to write is another animal altogether.
duffymo
Well OK, you're right. So it's a kind of ORM. Is this a good approach that I'm taking? All the input here is very much appreciated, thanks.
Kay Zed
A: 

It's generally called DDD - Domain Driven Design.

http://stackoverflow.com/questions/tagged/ddd

http://stackoverflow.com/questions/tagged/domain-driven-design

lubos hasko
A: 

Hi Kay

There are different ORM tools. Linq to SQL do a 1:1, which is not what you want.

What you're talking about overlaps with Domain Driven Design, where your design is driven by the domain, not the Database.

In this case, if you are using a relational Database you still need an ORM, and ORMs like Entity Framework and NHibernate allow you to flexibly "map" your entities to your database in any way you want, in a way that, if your Database needs to change for whatever reason, or you Entities have to change, for whatever reason, all you need to change is the middle "mapping" layer.

take a look at fluent nhibernate

andy