Click here to Skip to main content
15,667,475 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I am currently in the process of designing a REST API but got into a debate at work about the makeup of the objects. We currently have an Entity Framework model with some controller wrappers around them used as the DAL. We also obviously have the REST service part which will be based on ASP.NET Web API. This means we have two sets of objects - the data layer objects and the service layer objects.

The debate was around whether a third set was necessary for the core business logic layer where all the real work/processing gets done. I am of the mind that all other objects should convert into a Business Object which will be common and used in all core processing. This object will also then have methods on it to keep logic in a common place (as opposed to simply putting everything in static helper methods). However others feel its unmanageable and prefer to deal with both service and data objects in a mix-match approach in the business layer.

Can you recommend any good patterns or standards to follow?
wizardzz 27-Mar-13 16:31pm    
Why do they feel the Business Object would be unmanageable? I don't really understand their argument.
webdevchris 27-Mar-13 17:34pm    
I think it's because of having to maintain three sets of objects that on the face of it are all extremely similar. So the pattern above seems like a sensible approach?
wizardzz 27-Mar-13 21:43pm    
Wouldn't the 3rd object you suggest keep non logic code out of the 2 existing classes?
Prasad Khandekar 27-Mar-13 22:00pm    
I think business object should be the central object containing the business logic and it should be reused wherever possible. The REST API impl will merely be a wrapper around this BO. DTO's will be a primary way of data exchange between the BO, DAO/DAL & REST Wrapper.

1 solution

I'm a bit loathe to answer this as I don't think there is an answer, as such the following is an opinion and hopefully you'll get multiple opinions.

Given what you describe, I'd beef up the EF model and make that the business model, negating the need for the third set of classes, this keeps the architecture all nice and encapsulated. That said there are legitimate reasons for just treating the EF as a data store. Two that immediately spring to mind are: a very heterogeneous storage environment; the business model is significantly different to the EF model, which it shouldn't be if well designed I suppose) in which case the third layer makes all kinds of sense.

Thinking about what I've just said I'd run the following mental test:
1. Is most of the data persisted in the database?
2. Is the existing EF structured like any notional Business model (e.g. close mapping of business classes to the EF classes).

If the answer to the above is yes, I'd go for the EF model as business model approach but I'd make sure that persistence stuff doesn't bleed through, i.e. the EF classes are agnostic of the fact they are stored (other than the cruft the EF puts in automagically).
Share this answer
Pheonyx 28-Mar-13 9:30am    
Keith, I agree with your view point.
For the most part I find that combining object based business logic in the DAL (in this case EF) is the most effective solution.

The main situation where I may introduce a different structure is if the application requires a lot of non-persistent data objects (often when generating reporting objects, complex calculations) or where there is very complex cross object business logic requirements. In these situations I would look to introduce a separate Business Logic layer that focuses on these complex requirements.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900