MVC/MVP/MVVM - How to organize business logic

Question

This post is similar to in MVC/MVP/MVPC where do you put your business logic?, but I'm looking for more detail. I've bought into the Model as the place where the vast majority of business logic should reside. However, the Model, as far as I understand has a lot going on inside it: application state management, data persistence, repositories, data transfer objects, and possibly other stuff.

I have an application that has super complex business rules. When the user tries to perform one certain action in a view, there are about 20 different rules that must validate whether that action should be allowed, or whether the user must be prompted for additional information. I'd like to code these business rules one-per-method so as to support testability and documentation. Should these rules be in a repository class? Maybe in a services layer above the repositories? What's the best practice here keeping in mind that I'm using an ORM solution like Linq to SQL, EF, or nHibernate?

Answer 1

Firstly, don't forget that in MVP, you have the ability to maintain state in the View, so that's one less thing that's going on in the Model.

Both repository and service layer approaches might be applicable. I think I'd be tempted to explore both in parallel using a couple of test apps. As you go, you'll probably get a feeling that one is more suitable than the other, at which point you can concentrate on the right approach.

That may sound like wasted effort, but it'll be much less than the effort of switching approaches once development has started in earnest.