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

Question

В моей компании мы недавно приступили к разработке приложения MVC. Наша задача - написать уровень бизнес-логики, и в будущем он должен быть с меньшим обслуживанием.

У нас есть несколько веб-сервисов для добавления/обновления/удаления информации о пользователе.

Теперь мы должны добавить бизнес-логику, как:

Если Field1 на странице «хххх», то field2 должен находиться в диапазоне от 1000 до 2000 Если field3 некоторый отдел, то Field4 должен быть только в некоторые отделы.

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

До сих пор у меня есть: пишите все эти условия в Модели и проверяйте их при нажатии кнопки «Сохранить».

Заранее спасибо.

Answer 1

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

Возможно, это интересно прочитать this.

Также проверьте Where does the “business logic layer” fit in to an MVC application?

Answer 2

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

Answer 3

Для этого вы можете использовать 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, тогда есть альтернативы, но вам придется написать какой-то сантехнический код.

Answer 4

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

Answer 5

Мне нравится использовать 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 
    } 
} 

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

Answer 6

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

Если вам интересно получить дополнительную информацию о расслоении в приложениях уровня предприятия, я рекомендую вам Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App.