Is it a good practice to place reusable business logic C# files on an ASP.NET MVC project outside the controllers?

Is it a good practice to place reusable business logic C# files on an ASP.NET开发者_StackOverflow社区 MVC project outside the controllers? Or should I necessarily create another Class Library for that?

if you think you are going reuse the logic then create a class library. If not, then place it in c# files within your MVC project.

In a standard N-Layer architecture, you would have the following:

• Business Layer (dll) containing your POCOs and interfaces, as well as validation and other business related stuff.
• Data Access Layer (dll) (one or more, interchangeable) referencing the BL
• Application Layer (mvc, wpf, etc) (as many as you want) referencing the BL and the data layer(s) directly or indirectly if you are using an IoC container (preferred approach).

Business logic in an MVC application from my experience should be placed in their own classes.

I see controllers as things that get data from the front-end, and send data off to wherever it needs to do, and then get data back, and send it back to the front end.

The "wherever it needs to go" would include sending it through business rules, saving it/loading it from a database, and doing whatever you need to do. The controller should basically be a guy that says, "Oh hey, here's some data, I need to do this with it" but shouldn't actually be responsible for doing it.

I prefer to place everything outside of the Controller. Best practice is to have controllers only concerned with how to serve up requests, pass View Model data to pages and to consume updated View Model data. It is a really good habit to get in to, even for smaller applications.

I build enterprise applications with Business Logic, Data Access (database repository), and View Models each as layers completely separate from my Models, Views and Controllers.