From the course: ASP.NET MVC: Building for Productivity and Maintainability

Creating separate projects for application and business logic

From the course: ASP.NET MVC: Building for Productivity and Maintainability

Start my 1-month free trial

Creating separate projects for application and business logic

“

- [Instructor] One of the core concepts of the model-view-controller design pattern is separation of concerns, the idea that keeping business logic, view logic, and application logic all separate from one another will make each of them more straightforward and therefore more maintainable. In this video, I'm going to focus on that first type of logic, business logic, and how I go about keeping it separate from my ASP.NET MVC website code. Now, just to be clear, when I say business logic, I mean the logic in your application that has to do with the way your business works. For instance, how you manage your product inventory or fulfill customer orders. This kind of logic has absolutely nothing to do with whether your application is written in ASP.NET MVC or even whether it's a web application at all. Theoretically, this type of logic could execute in any environment regardless of the UI technology or framework that's used. So what does all of this have to do with ASP.NET MVC? Well, when you first create an ASP.NET MVC project, Visual Studio will create three folders for you, appropriately named models, views, and controllers. For instance, here's what the sample application for this course looked like when it was first created. The majority of ASP.NET MVC tutorials, including my own, will tell you to begin creating classes in the models folder that do things like access a database or calculate sales tax. Now, this advice isn't necessarily wrong, meaning if you're going to put everything into a single project, well, then those types of classes should go into the models folder. However, I don't like to put everything into a single project. I like to really reinforce the fact business logic should not be tied to the ASP.NET MVC application. So the first thing I typically do after creating a new ASP.NET MVC application is immediately create another project in the same solution to house my business logic. What you call this project is completely up to you. Some people like to call it core or common or even models. Some people prefer to create several different projects depending on the complexity of their application. For example, splitting data access out into its own project as well. Now, here's a screenshot of what the HPlusSports solution will look like when you first open it up in the beginning of next chapter. You can see that I've chosen to create one single project named common, and I have put all of the data access logic and other business related classes into this new project. It is, however, also worth pointing out that the models folder still does exist in the ASP.NET MVC application project, except now, it contains only models related to the web application, such as view models, a concept I'll dive into later in this course. Though it may seem simple, the practice of keeping your business logic in a completely different project from your web application really helps reinforce the separation of concerns between the two. For instance, you wouldn't think twice about adding a reference to an ASP.NET MVC assembly in your web application project, why would you? However, if you found yourself adding that same assembly to a business logic project, well, it might make you pause to consider whether the logic you're implementing is truly business logic or if it might happen to be some web-specific logic that's starting to creep in. Splitting your business logic into its own project is the first bit of advice that I generally give to folks looking to get their large ASP.NET MVC applications under control. And it's my first recommendation to you in this course.

Contents