Database Mapping as Data Access Layer for Business logic

AS we know that during mapping of database to business

logic, We mapped table to class with columns to Properties.

 but if we have complex queries with multiple joins

and "Group By" clause then what is the mapping of this

query to business ligic side plus how we display data

retrieved by query to the user.

How we handle other issues,

Keeping all aboive question in mind how we formed a Data Access Layer at Business Logic side , or what will be design look like.

How many Interfaces or abstract functionality it have.

Will you suggest a design or any good link that further

elobarate this design logic.

Thinks in advance!

Thanks in advance!
Who is Participating?
gabesoSolution ArchitectCommented:
Do not map one table to one class: While a simple approach it is very problematic and I think causes major issues for the design.

Classes model domain abstractions and tables are part of a a relational design - they are different things doing different jobs.

Spend some time modelling the data in a relational database and separate time modellnig domain classes without binding one to the other on a one-to-one basis.

You can then create procedures and views on the database that let you serialise and/or deserialise the objects efficiently.

As a test you have to ask yourself if you are able to search for serialised objects efficiently and if you can't then you have a problem.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.