I am asking this question because after developing a few small custom cms solutions in a framework, I developed the idea that Models can be easily substituted with ORMs which ease up the task of validating, getting and setting data, as thats all they are needed for.
I recently got an order for a complex custom client management solution. After researching a bit on how to proceed on it, I found this:

Now the idea is not new as thats what i had read about the MVC approach, models handle the business logic. But I am finding it hard to plan out an approach in which Models handle the business logic and are classes which are complete in themselves because of the type of work i have gotten used to.
Please help me out here by explaining the idea and pointing me to some examples, articles etc

  • Nice question. I haven't thought about this before. Aug 27, 2011 at 13:02
  • Nice link ...what dev technology are you using ...ASP.Net?
    – IAbstract
    Aug 27, 2011 at 13:39
  • IAbstract, I use the black sheep of dev technologies, php. However, it has become pretty good since 5.3. Used to work in codeigniter, now work in fuelphp (basically a codeigniter for php5.3)
    – kapv89
    Aug 27, 2011 at 13:50

1 Answer 1


You should read more about Domain Driven Design. Basically you try to capture the requirements of the business into a pure model (in oop mostly object models) which can do all necessary business logical tasks. This model can then be invoked from an application layer (e.g. the view or the controller in MVC, in MVP you call it and adjust it for the GUI in a Presenter). The model should also be as ignorant of persistence and other technical things as possible.

Encapsulating the business logic in such a domain model has some great advantages:

  • Reusability
  • Ease of use and extension
  • Generally leads to a better architecture
  • It clearly communicates coherences and the business requirements ...
  • ... and thus improves communication between developers, customers, analysts etc.

I recommend Eric Evan's book on Domain Driven Design for further reading, as it will point you in the right direction and give you some good examples on where to put which logic. I bet that by the time you've read it, a large percentage of your entities will contain more than flat data.

But I am finding it hard to plan out an approach in which Models handle the business logic and are classes which are complete in themselves.

I assume, that by model you're mostly referring to entities in this context. Putting business logic/behaviour in the entities is not a trivial task. But you should always think about what an entity is and what an entity does. Does it have some responsibilities or behaviours? Sometimes it's ok to have flat entities if behaviours or responsibilities are better expressed as services.

Suppose you have an animal. While its attributes can be saved flatly to a database, it has some behaviour, too. It needs to eat. But a herbivore won't eat meat, so you've got to make sure it'll show its behaviour when the programmer wants it to consume meat by force. It can move and it can make it's own unique noise. These are some things that should be modelled into the entity for example. You sure wouldn't rely on procedural services to make those animals eat, move or make their noise.

But all examples are shallow without a concrete business domain. So think about your business domain and about its entities, behaviours and responsibilities. An other business domain may contain entities which look much the same to an outsider, but are indeed something entirely different or show a totally different behaviour. The model needs to first and foremost depicture the domain of its users as accurate as possible.

  • thats a very informative answer. Thanks. From what I understand, I might need to extend the orm classes in order to add the functionality i might need, or rather, define a second layer of models over the ORM layer which applies the business logic to the objects it works on. Am I getting it right? (Also, I am ordering that book right away)
    – kapv89
    Aug 27, 2011 at 13:56
  • Can't edit anymore, but by extending the ORM calsses, I mean extending the models which represent the database
    – kapv89
    Aug 27, 2011 at 14:03
  • @kapv89: Sometimes it's better to wrap/extend the classes, primarily for transfers. See the DTO pattern (Data Transfer Object) to get some more insight.
    – Falcon
    Aug 27, 2011 at 15:53
  • I have been thinking about what you said in your post and reading about fat models and Domain driven Design. I think I have some idea now about how to go about this project. Thanks. i have also ordered that book and will read it while working on this project
    – kapv89
    Aug 27, 2011 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.