Hi,
In need of some help. I am confused about how to layout my application structure. I have looked at open source apps but still confused as they each have different structures.
I am thinking to have a separate folder for Business Logic. Within that, i will have a class for lets say customerService. This class will contain all linq queries. I will then have another folder under Business Logic for data classes. In this i will have a class customer. This will contain the getters and setters.
I assume that the model folder will contain a CustomerModel.
So the structure will be
Business_Logic
------Data
--------------customer (getters and setters)
------DBAccess
--------------customerService (linq queries)

Model
------CustomerModel (????????)

Controller
-------CustomerController

View
-------Views here etc etc

Questions:
Am i headed in the wrong direction for the MVC application structure? Do I need a Business Logic folder?
If the above example is more or less correct, what functions will the CustomerModel hold? Will it literally just reference the Business Logic customerService class?
I can’t find any relevant material on the Internet. I am literally struggling in getting the structure correct.

Generally I advice creating an entirely new class library for the business layer. You can easily do that and have it be in the same solution so it still shows up in visual studio next to the mvc project.

The setup you have for the Business Logic folder is ok. I tend to break it like so

Business Layer
-Entities //contains my model objects
-Interfaces
-DataAccess
-Services

In the asp.net mvc project I use the models folder to onnly hold ViewModels. Which are specific representations of your models only relevant to the web.

Also, my contrllers don't talk to the data access code in my business layer, instead the controller has an instance of service class that knows how to talk to the database. The advantage of this is that I can swap out dataaccess code without impacting the controller. This comes in really handy when creating unit tests.