7

I am building a small application and want to save my business objects to a database.

I have my business objects and a model that acts as a container for my business objects and provides methods for creating and deleting them. Updating the business objects is done by directly altering the objects attributes. I also have a user interface and a presenter for user interaction and a database communicator that knows how to insert/delete/update my business objects into the database.

I want to constantly update my database if a business object is created, deleted or altered.

The easiest way would be to give my model a reference to the database communicator and call the insert/delete methods, when a business object is created/deleted in the model and call the update method from my presenter, when the user alters the business objects attributes via the user interface.

Is that an acceptable way of handling a database in a MVP/MVC scenario, or is there usually a tighter coupling between the database and the model layer? If so, is there a best practice to let my model know that one of the business objects has changed, or do i just use whatever the language im using offers me?

Luca Fülbier
  • 543
  • 6
  • 12

1 Answers1

12

I've seen it done two ways.

The first way is to do everything using CRUD methods. That's essentially the way you are describing: Create, Read, Update and Delete. Most Object-Relational Mappers (ORM's) support these four operations.

The second way to do it is to provide a Service Layer. The Service Layer exposes methods that embody business operations. In turn, it translates those business operations into the appropriate CRUD methods.

At this point, it might be useful to discuss architecture a bit.

First, note that MVC and MVP are primarily about UI. That is, they don't particularly care about what happens in the business domain. While UI can, and often does, reflect the nature of the business domain in the data that it displays and the interactions that it makes with the user, the heavy lifting is done in the Model portion of MVC or MVP.

In a web page, MVC typically looks like this:

Model <--> Controller <--> View

The Model is the "everything else" part of these patterns, the part that doesn't concern itself with UI or routing or any of those mechanics. You may have heard the phrase "thin controller, fat model." That means that business logic doesn't go into the controller. In turn, the View doesn't concern itself with data, for the most part. It's just a surface; the task of filling it with data typically falls on a ViewModel object, which is typically assembled in the Controller with data derived from the Model. 

Model <--> Controller <--> ViewModel <--> View

The View displays data and accepts typed-in data from the user. It might have some interactive and validation capabilities, but even validation is not wholly performed in the client (because data from a client can't be trusted). Validation is relegated to the server, where the Controller (who acts mostly as a switchyard) typically delegates such validation to the Model.

In other words, most of the application logic that actually does anything useful is pushed as far back as it can be towards the Model.

It is for all of these reasons that MV* applications typically have some sort of Service Layer, even if it's just an internal one. 

Database <--> ORM <--> Service Layer <--> Controller <--> View Model <--> View
|-------------- Model -------------|

The Service Layer relieves the Controller from having to think about Business Logic, and allows your Database Communicator (i.e. your ORM) to only have to think about CRUD.

Further Reading
P of EAA: Service Layer
Fowler on UI Architectures

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • Very nice explanation, thank you! I should probably buy Fowlers book in the future, i keep coming back to his articles a lot lately ;-) – Luca Fülbier Feb 23 '16 at 01:41
  • 1
    Good answer. Important to note that having everything with badly implemented DDD in mind results in fat models that are very hard to modify. Personally i prefer a simple model with a bunch of properties and no methods and then the service layer to do modifications and ORM (or whatever class you use for that, CoreData etc) to do actual connecting to the db and saving. – zaitsman Feb 23 '16 at 12:05
  • So in an application that uses hibernate, MySQL and a DAOLayer, the classes that represent the database tables and have @Entity annotations are just PART of the model but they don't solely make up the model? – user3629892 Apr 16 '17 at 14:01