REST API Architecture

Question

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?

Posted 27-Mar-13 8:21am

webdevchris

Add a Solution

Comments

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

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Keith Barrow · Answer 1 · 2013-03-28T03:09:00

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).