2

在我的公司,我们最近开始开发 MVC 应用程序。我们的任务是编写业务逻辑层,并且将来它应该减少维护。

我们有几个网络服务来添加/更新/删除用户信息。

现在我们必须添加如下业务逻辑:

如果页面上的 Field1 是'xxxx',那么 field2 应该在 1000 到 2000 的范围内。如果 field3 是某个部门,那么 field4 应该只在某些子部门中。

所以我们必须设计这个层,以便将来我们的管理员(没有编程知识)可以进入并更改逻辑,以便它能够工作。请给我一些建议。

到目前为止,我得到的是:在模型中编写所有这些条件并在用户单击保存按钮时验证它们。

提前致谢。

4

6 回答 6

4

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?

于 2013-10-11T15:44:54.913 回答
1

将其保存在不知道您的 ui 层的单独程序集中。您的模型可以在这里执行业务规则。我个人喜欢在 Csla 框架之上构建业务层,它可以让您构建具有强大规则的丰富模型。它面向 ntier 开发,但我相信它也与 ddd 兼容。

于 2013-10-11T15:46:38.583 回答
1

我喜欢使用 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
    }
}

使用这种设置,我的模型和验证器位于同一层,但我不会用业务逻辑混淆我的模型类。

于 2013-10-11T16:13:26.877 回答
1

当您谈论时layering,您的业务层应该与表示层分开。ASP.NET MVC 是一种表示技术;因此,您的业务层将在不同的程序集中。此外,您的业务模型不会直接在您的视图中使用;您可以使用 ViewModel 验证用户输入,当一切正常时,将 ViewModel 数据传输到业务实体。

如果您有兴趣获得有关在企业级应用程序中分层的更多信息,我推荐您Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App

于 2013-10-11T17:02:09.117 回答
0

您可以使用它DataAnnotations来执行此操作 - 事实上,数据注释不仅仅支持服务器端强制执行模型有效性。他们还可以为实体框架和客户端脚本提供提示,以便进行数据库/客户端验证,并向 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

如果您没有使用实体框架,那么您可能需要考虑它 - 如果您使用的是另一个 ORM,那么显然使用支持它的工具。如果您不使用 ORM,那么还有其他选择,但您必须编写一些管道代码

于 2013-10-11T15:46:47.470 回答
0

业务逻辑应该在模型层,我不认为没有编程知识的人可以改变业务逻辑,他至少必须有基本的编程知识

于 2013-10-11T15:49:45.210 回答