MVC/MVP/MVVM - How to organize business logic

Question

This post is similar to http://stackoverflow.com/questions/534233/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

If they are business rules, I would put them in a database table so they're easy to change.

The code itself is then business-rule stupid and doesn't care about the content of the rules, just the structure of the rule container.

Regarding your comments below, if you need to limit your approach to a code-centric one for some other reason, that's fine, it just makes developing the project significantly more expensive.

The more complex the rules are, the more you benefit from having them table-driven instead of hard-coded. The hard part can be coming up with a model for the rules, if you're not used to it. After the model's built, the development is straightforward.

Answer 2

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.

Answer 3

Having a look in how CSLA.NET handles business rules might be interesting: http://www.lhotka.net/cslanet/

Answer 4

Last week was my first presentation while playing the Solution Architect Role in ArabiaGIS, so I tried to start with an introduction to design patterns, and my first subject was the Model-View-ViewModel design pattern. in the presentation I tried to introduce the design pattern concept, showing its importance and the goals off applying it.

The presentation will focus on the history and the importance of MVVM and then go into the detailed of this important design pattern for architecting a WPF application.

To see the presentation: http://solutionsarchitecture.wordpress.com/2009/11/13/introduction-about-mvvm-model-view-viewmodel-design-pattern/