Rich object model in the context of a good REST API and of an existing rich object model on the server-side

Question

First off, let's frame this question in the context of a good REST API and an existing rich object model on the server-side, as well as modern web architecture (MVC frameworks like angularjs).

I'm debating whether or not to use a rich object model with my next project. The alternative is just using very light-weight POJO objects (pretty much whatever the API gives me) and using these in a non-persistent (between views) manner, i.e. no "application state". Just load what you need for the current operations and then get rid of it when you don't.

The risks of a rich object model that are giving me pause are:

1. Testability - it could be harder to unit test a complex object model

2. Performance - with a large object graph, the performance of the app could suffer. Contrast that with lightweight POJO's that get created and destroyed as needed, the app stays nimble.

3. Complexity - a complex object model could be orders of magnitude more complex than a lightweight app that just loads what it needs at the moment. This could also make it harder to modify...

4. Harder to modify - a rich object model creates a multitude of dependencies. This makes it harder to change things down the road.

I'm leaning towards a lean, light-weight web app that just loads what it needs at the moment and destroys what it doesn't.

Answer 1

When it come to dealing with a web client side frameworks, best approach is to keep objects simple, because

1. API Complexity -> Less complex of API methods

2. Concurrency -> If a complex object is loaded, and it's life time is apparently longer and when it needed to persist there could higher probability that it might have changed by some other user / process. Which could cause errors. By keeping the lifetime of object lower this can be avoided.

3. Validations -> when you have a rich object model there are more and more complex validations you need. If the same model spans over multiple views (chances are it will) then showing the messages when persisting the object would be a complex task.

4. Performance -> Even it is a minor change, if a rich model is used entire model need to be fetched causing access to multiple tables and large amount of data is fetched.

Answer 2

You can have a lean, lightweight app and still have a rich object model.

If you're using Angular, that means you're probably writing a single-page application and driving the UI from web services. Those web services should provide you with the data you need for the UI. On the server, you can have a data model and application layer as complex as your domain requires.

ViewModel objects are the layer of abstraction that allows you to have your complex object model, while still keeping the UI as lean as you need it to be.

Answer 3

I have done both of these approaches in the past and I tend towards the simplified POJOs. The main reason is, it allows and forces in that the business logic is actually performed on the server.

When we used to send the full rich model to the client our client code started accumulating little bits and pieces of business logic everywhere and got rather nasty. And that made code reuse completely impossible as it was tied to a particular screen.

So instead I prefer to just preprocess the data exactly for the need of the client and let it deal with the display only.

The other reason I have seen the small POJOs work better is speed. (Which is not true in all cases). But assuming that the user only wants to modify this small portion. With the rich model you tend to have to pull in the entire thing to the client modify the small bit and the save the whole thing back. Depending on the size of your model and type of user interaction this may or may not be a problem.

And last is interactivity and concurrency. (Which depending on your application may or may not be needed.) But custom simple POJOs and services allow you to save changes as your user goes, in small pieces and refresh often from the database. Which in turn cuts down possible concurrency issues, that come in when two users modify the same big chunk of data and then save back.

On the other hand, if you are dealing with a large form with multiple sub-screens that gets filled out once, it might be better to send the entire model to the client process it there and save it back. This has the problem of having the business logic on the client. The way we have worked around this in the past is to encode the business logic in the model (such as sending validation rules as part of the model).

Answer 4

Sending data over the wire to an API Is, I think, one of the key drivers of an ADM/POCO style approach to programming (see my question : https://softwareengineering.stackexchange.com/questions/283725/ where i touch on some of the same points)

If you take the OOP route, you are faced with the problems of serializing a model which jealously guards its data and then creating a similar model on the server side from that data which may need maybe of the same basic functions, but all the best practice guides (for good reason) warn against using the same model on both sides of the service.

The ADM route makes the whole thing simpler, but there is a danger here that as the functionality of the service becomes complex, your simple procedural approach will result in 'bad' code, futhermore, there is a temptation for this style to spread to the application side of the interface.

However, I do think you can have the best of two worlds here. With the service you cant get around the fact that you are programming a function which takes a data struct as a parameter and making your program match this fact is the best thing to do.

As you can see in my example though, there's no reason not to make the service itself follow OOP within the restraint of 'you must receive and return a struct'

On the app side the restriction of 'some methods are not run on this machine' are harder to deal with. You can inject the service into the model and then have model.method() calling the service, but this will lead to some very contrived code in my opinion.

Or you can use the ADM approach of calling the methods on the serviceclient objects passing in your struct like models. Again this non OOP approach matches the reality of the situation, whilst enabling you to keep the rest of your code sensible