Где хранить бизнес-логику в архитектуре MVC?

Бизнес-логика должна храниться внутри модели. Вы должны стремиться иметь большую модель и маленький контроллер.

Возможно, вам будет интересно прочитать это это.

Также проверьте Где находится «Слой бизнес-логики» подходит для приложения MVC?

Храните его в отдельной сборке, которая не знает о вашем слое пользовательского интерфейса. Ваши модели могут пойти сюда и обеспечить соблюдение бизнес-правил. Мне лично нравится строить бизнес-уровень на основе фреймворка Csla, который позволяет создавать многофункциональные модели с мощными правилами. Он ориентирован на развитие ntier, но я считаю, что он также совместим с ddd.

Когда вы говорите о layering, ваш бизнес-уровень должен быть отделен от уровня презентации. ASP.NET MVC - это технология представления; Итак, ваш бизнес-уровень будет в другой сборке. Кроме того, ваша бизнес-модель не будет использоваться непосредственно в ваших представлениях; вы можете использовать ViewModel для проверки ввода данных пользователем и, когда все будет в порядке, передать данные ViewModel в Business Entity.

Если вас интересует дополнительная информация о многоуровневых приложениях корпоративного уровня, я рекомендую вам Microsoft Spain - пример N-Layered .NET 4.0 с доменной ориентацией Приложение.

Мне нравится использовать Entity Framework и Fluent Validation для создания уровня домена, который содержит как модели, так и валидаторы. Настройка выглядит так:

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
    }
}

Используя эту настройку, мои модели и валидаторы находятся на одном уровне, но я не забиваю свои классы моделей бизнес-логикой.

Бизнес-логика должна быть на уровне модели, и я не думаю, что кто-либо без знаний программирования может изменить бизнес-логику, он должен иметь хотя бы базовые знания в области программирования.

Для этого вы можете использовать DataAnnotations - на самом деле аннотации данных позволяют не только проверять достоверность модели на стороне сервера. Они также могут давать подсказки для Entity Framework и сценариев на стороне клиента для проверки на стороне базы данных / клиента и добавлять метаданные к методам и свойствам, которые MVC может проверять.

например для модели:

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; }
}

И да, сохраните как можно больше бизнес-логики на бизнес-уровне (модели). Если оставить в стороне общие проблемы, ваши компоненты должны быть как можно слабее связаны. Таким образом, есть центральное место для внесения изменений, ваш код более тестируемый и обслуживаемый, а также помогает поддерживать согласованность программирования (что помогает новичкам в вашем проекте быстро освоиться)

Если у вас есть более сложные правила, вы можете написать валидаторы EF.

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

Если вы не используете Entity Framework, вы можете подумать об этом - если вы используете другой ORM, тогда, очевидно, используйте инструменты, которые его поддерживают. Если вы не используете ORM, есть альтернативы, но вам придется написать код для сантехники.