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:http://blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/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
How to make models do more than setting and getting data and validation
web applications;mvc
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 architectureIt 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.