在 MVC 体系结构中保存业务逻辑的位置

本文关键字：位置 业务 保存 MVC 体系结构 | 更新日期: 2023-09-27 18:35:03

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

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

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

如果页面上的字段 1 是"xxxx"，则字段 2 应在 1000 到 2000 的范围内如果字段 3 是某个部门，则字段 4 应该只在某些子部门中。

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

到目前为止，我得到的是：在模型中编写所有这些条件，并在用户单击保存按钮时对其进行验证。

提前谢谢。

在 MVC 体系结构中保存业务逻辑的位置

业务逻辑应保留在模型中。您应该以拥有一个大模型和一个小控制器为目标。

您可能会发现阅读本文很有趣。

另请检查"业务逻辑层"在 MVC 应用程序中的位置？

将其保存在一个单独的程序集中，该程序集不知道您的 UI 层。 您的模型可以转到此处并强制执行业务规则。 我个人喜欢在 Csla 框架之上构建业务层，它允许您使用强大的规则构建丰富的模型。 它面向 ntier 开发，但我相信它也与 ddd 兼容。

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

如果你有兴趣获取有关企业级应用程序中分层的详细信息，我建议你Microsoft西班牙 - 面向域的 N 层 .NET 4.0 示例应用。

我喜欢

使用实体框架和流畅验证来创建包含模型和验证器的域层。设置如下所示：

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来执行此操作 - 事实上，数据注释不仅支持服务器端强制执行模型有效性。它们还可以向实体框架和客户端脚本提供提示，以便进行数据库/客户端验证，并将元数据添加到 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，那么还有其他选择，但您必须编写一些管道代码

相关文章：