Where to keep business logics in MVC architecture?

StackOverflow https://stackoverflow.com/questions/19322132

Question

In my company we have recently started developing MVC application. Our task is to write the business logic layer and in future it should be with less maintenance.

We have couple of web services to add/update/delete user information.

Now we have to add the business logics like:

If Field1 on the page is 'xxxx' then field2 should be in the range of 1000 to 2000 If field3 is some department then field4 should be only in some sub departments.

So we have to design the layer so that in future our admin(who don't have programming knowledge) can go in and change the logics so that it will work. Please give me some suggestions.

So far what i have got is: Write all these conditions in Model and validate them when user click save button.

Thanks in advance.

Was it helpful?

Solution

Business logic should kept inside the model. You should aim to have a big Model and a small controller.

You may find this interesting to read this.

Also check Where does the “business logic layer” fit in to an MVC application?

OTHER TIPS

Keep it in a separate assembly which doesn't know about your ui layer. Your models can go here and enforce business rules. I personally like building the business layer on top of the Csla framework, which lets you build rich models with powerful rules. Its geared toward ntier development but I believe its also compatible with ddd.

When you are talking about layering, your Business layer should be separated from Presentation Layer. ASP.NET MVC is a presentation technology; so, your Business Layer would be in different assembly. Additionally, your Business Model wouldn't be used directly in your views; you can use ViewModel to validate user input and when everything was OK, transfer ViewModel data into Business Entity.

If you are interested to obtain more information about layering in enterprise level applications I recommend you Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App.

I like to use Entity Framework and Fluent Validation to create a domain layer that contains both models and validators. The set up looks like this:

public abstract class DomainEntity
{
    private IValidator validator;

    protected DomainEntity(IValidator validator)
    {
        this.validator = validator;
    }

    public bool IsValid
    {
        get { return validator.IsValid; }
    }

    public ValidationResult Validate()
    {
        return validator.Validate();
    }
}

public class Person : DomainEntity
{
    public int Id { get; set; }
    public string Name { get; set; }

    public Person() : base(new PersonValidator())
}

public class PersonValidator() : AbstractValidator<Person>
{
    public PersonValidator()
    {
         ... validation logic
    }
}

Using this set up, my models and validators live in the same layer but I don't muddy up my model classes with busines logic.

Business Logic should be in Model layer, and I don't think that anyone without programming knowledge can change business logic, he must have basic programming knowledge at least

You can use DataAnnotations to do this - in fact data annotations enable more than just server side enforcing of model validity. They can also give hints to Entity Framework and client side scripts in order for database/client side validation, and add metadata to methods and properties that MVC can inspect

e.g. for a model:

class PersonDetailsModel
{
    [Required("Please enter a name")] // Don't allow no value, show the message when the rule is broken (if client side validation is enabled it shows when you tab off the control)
    [DisplayName("Full Name")] // Hint for MVC - show this when using the helper methods e.g. in MVC4 Razor syntax @Html.LabelFor(model => model.Name)
    public string Name { get; set; }
}

And yes, keep as much business logic in the business layer (model). Cross-cutting concerns aside, your components should be as loosely coupled as possible. This way there is a central place to make changes, your code is more testable and maintainable and it also helps you to keep your programming consistent (which helps newbies to your project get up to speed quickly)

If you have more complex rules, you can write EF validators.

http://msdn.microsoft.com/en-gb/data/gg193959.aspx

If you aren't using Entity Framework then you might want to consider it - if you are using another ORM then obviously use the tools that support that. If you aren't using an ORM, then there are alternatives but you'll have to write some plumbing code

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top