ASP.NET MVC application structure [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

I am developing an MVC application using a mysql database.

I searched a lot through SO and other sites about the architecture/structure. I found a lot of similar questions but I am still in doubt.

In my applications there is a categories section; the structure is shown below:

View:

Category - (views in category folder listed below)

        CreateCategory
      
        DeleteCategory

        ManageCategory

    

Controller:

CategoryController - (action names listed below)

        CreateCategory
      
        DeleteCategory

        ManageCategory

Model: This is where I have doubts. I have a model named CategoryModels but I don't know if I doing things the right way or not. I don't know where I should put the service functions - for example where I put functions to create or delete categories.

What I did is create a CategoryServices class inside CategoryModel.cs and write functions inside that. DAL file is put in app code folder, so to access the DB the function will create an object of DAL and call it. Is this the right way?

In CategoryModels.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Data;
using System.Web.Mvc;
using System.Web.Caching;

namespace TraktorumMVC.Models
{
    public class CategoryModels  // contain properties for the 3 views (CreateCategory,DeleteCategory and  ManageCategory
    {
          public IEnumerable<SelectListItem> CategoryList { get; set; }
          public IEnumerable<SelectListItem> AvailableCategories { get; set; }
           //etc..........
    }

    public class CategoryServices  // this class contain all servi开发者_如何学Cce functions related to categories   
    {
       public int RemoveCategory(int categoryId) // this will remove a category
       {            
        int status = -1;
        try
        {
            string query = Resources.Queries.RemoveCategory;
            DAL objDAL = new DAL();               //DAL file is in Appcode folder. IS this right way
            string[] inParamNameArray = { "Id"};
            string[] inParamValueArray = { categoryId.ToString()};
            object[] inParamTypeArray = { DbType.Int32 };
            status =Convert.ToInt32( objDAL.ExecuteScalar(query, inParamNameArray, inParamValueArray, inParamTypeArray, true));               
        }
        catch (Exception ex)
        {
            DeveloperLog.WriteExceptionLog(ex, "CategoryServices.RemoveCategory");
        }
        
        return status;
      }

       public bool InsertCategory(int parentCategoryId, string icon, string name)
       {
        //bla bla
       }
    }
}

Is this right way to do this? Did this break the model concept?

---

The "Model" in ASP.NET MVC is not very prescriptive, and is certainly less prescriptive than the Views or Controllers.

That said, there isn't necessarily a right or wrong way to do your model, but there are a few popular/common approaches that people take:

• Leverage an ORM like Entity Framework (EF) or NHibernate to be your model. This works out well on simple sites that are mostly CRUD driven. In your situation, EF could handle all of the CRUD work you need to do on categories.
• Another common approach to is to leverage some sort of services layer which might encapsulate business and data access logic. This layer might return to your application data transfer objects - very simple, data only containers - that you can change and send back.
• Either way, it's a good idea to separate your "View Model" from your "Domain Model". An example of this is not simply passing Entity Framework controlled objects to the View for rendering. Instead you'd map those objects (and potentially others) into a "View Model" specifically created for just that view. A popular tool to help developers accomplish this is the excellent http://automapper.org/

In your situation, if you can, I'd recommend putting in an ORM to handle the persistence of categories. If your current DAL is doing more than just persistence, then I'd recommend you separate it out to a service, with corresponding interface, that your controller can get a reference to and use to drive your application forward.

---

You don't really have a Category model here, what you have is a view model for a particular part of some views. As @nikmd23 alludes to, you probably want to separate your view model and domain model. A domain model is something that describes the data which makes up your system. A view model is something that describes how you would like to share that data through an interface.

In this case, start by creating a domain model, something like:

public class Category
{
    public string Name { get; set; }
    public int Id { get; set; }
}

Then your DAL contains some functionality for getting a collection of Category objects:

public interface DAL
{
    IEnumerable<Category> GetCategories();
}

And when you want to construct a view model of your categories, you would map it to view model:

var dal = new DALImplementation();
var categories = dal.GetCategories();
var categoryListViewModel = categories.Select(m => new SelectListItem 
{ 
    Text = m.Name, 
    Value = m.Id.ToString() 
});

There are many different implementation patterns for each of these steps, but the whole idea is to start by creating a domain model, then build your services to interact with those domain models, and for each request with a view, construct a view model which only shows the exact information you want to share with your user.