Where to put functions that help me execute controller tasks?

Question

I'm currently working on an ASP.net MVC web site project.

I've put all database related stuff in my model, such as queries and update/delete/save functions.

I also created a couple of controllers that execute the logic. I added a Helpers namespace and inside that namespace there are a few classes that contain logic for pagination, internationalization etc.

I was wondering what is the best practice for placing functions and classes that do some general stuff, like generating an invoice?

Answer 1

As I expressed in a comment above, I’m too very much interested in this question.

First, it seems wrong to create additional directories (for the other classes and utilities) directly in your ASP.NET MVC project. Also, I don’t feel that it should be in model. To me, model is more or less data classes which in some way represents the database (or the data we are trying to model). On top of that, often the business functionality (or the "real" pieces of code in your application) deals with several model classes at a time, and so there may not be a natural place for it in some model class.

So I think I am leaning towards the following schema:

• Make controller actions very small; just few lines of code each.
• Keep model simple and mostly functionless, and put it into a separate project.
• Put all your code that does all the "real" work (the "business layer") into a separate project.

This way you will get a complete freedom in choosing your own namespaces, you will be able to create any number of utility classes, functions, and generally able to structure your code as you like without being restricted by ASP.NET MVC.

This is just an idea. At the moment I’m working on my first larger ASP.NET MVC application. So I’m actually going to learn whether and how this works in practice.

Answer 2

I have Model classes that have Crud and Poco like you have.

Apart from that I have Viewmodels that are used for the typed Views.

My Viewmodels are pretty big and used in a couple of views (around 10-15 viewmodels for the whole appplication). In my application these ViewModels ended up as being the perfect place for the code that seamed to big and repetetive for the controller actions.

For example I have some logic that is pretty near to UI when I add a Product to the Cart. I now have a method in the ViewModel: AddToCart(IProductService productService, ICartService cartService).

Answer 3

You might consider creating some services that you inject into your controllers.

It's almost too wide a question.

Answer 4

This kind of business logic should be somewhere in your Model.

However, I find that when there is just something that doesn't really "fit" anywhere - and you might be tempted to create a Utilities class - this is usually a good place to utilize Extension methods.

Perhaps you can add extension methods on your dataset to help you with pagination?

Answer 5

I you really need the best practice, consider looking at Domain Driven Design. It doesn't suit all projects and does require good OOP skills, but I think it is without doubts a "best practice"... as long as you can afford it ;-)

Notice that you do already violate DDD since you use Active Record pattern (put persistence logic into entities). So, I do not say that you have to follow DDD. But it will be useful to grok anyway.

Answer 6

I think the best solution to this question about practice is: Put the logic in the Model if it's going to be used across controllers. If it's controller specific, just drop it in your controller. When I say the Model, this could be a separate project that conatins your Entity Data Model, or it could be a View Model, or it could be just the Models folder of your MVC project.