N 层结构中的实体框架和 BreezeJS答案

【问题标题】：Entity Framework and BreezeJS in a N-Tier StructureN 层结构中的实体框架和 BreezeJS
【发布时间】：2014-12-23 15:54:26
【问题描述】：

这是一个具体的问题，但我不知道如何让所有部分正确地结合在一起。我正在尝试使用 SQL Server 数据库启动一个项目，该数据库使用 Entity Framework 为带有 AngularJS 前端的 BreezeJS 提取数据。我的问题特别关注 N-Tier 和 BreezeJS 关系，以及如何使用 Entity Framework 设置实体才能使其正常工作。

我的项目从后端到前端是这样的：

DAL（数据访问层）

业务规则层

Web API 层

AngularJS 前端

这些层中的每一层都在不同的项目中，我希望将它们分开，尤其是 Web API 和前端，以便将来可以在不暴露业务逻辑的情况下分发 API。

理想情况下 DAL 层或多或少是我的数据库 E.X 的实体版本。

数据访问层

public class BUILDING
{
    public BUILDING()
    {   // A List of building visitors
        this.VISITORS = new HashSet<VISITOR>();
    }

    [key]
    public int ID { get; set; }
}

public class VISITOR
{
    public VISITOR() { }

    [key]
    public int ID { get; set; }

    // The building the visitor visited
    public virtual BUILDING BUILDING { get; set; }
}

DAL 之上的层是业务规则，我希望它处理所有逻辑和数据检查以及其他任何需要的东西。这是我开始遇到问题的地方。如果我想要一个名为 ATTRACTION 的业务规则对象，它包含 DAL 对象 BUILDING 和 VISITOR，我将如何去做？

业务规则层

public class ATTRACTION // This is the object I want Breeze to track
{
    private BUILDING _building;
    private List<VISITOR> _visitor;

    public int Id
    {
        get { return _building.ID }
        set { _building.ID = value; }
    }

    public void AddVisitor(int id)
    {
        // Functionality
    }
}

Web API 层实际上应该只是掩盖了业务规则层并且几乎没有功能，AngularJS 前端已经完成。

我真正遇到的问题是让 BreezeJS 使用 BR 层而不是 DAL 层的对象。我的数据设置是否可行？我知道（或至少相信）BreezeJS 需要 DbContext 项，但我找不到用它包装 BR 层对象的方法。归根结底，我真的只想使用 BreezeJS 来实现其更改跟踪功能。任何帮助都将不胜感激，如果需要，我可以提供更多代码示例我只是想将帖子保持在可管理的长度。

【问题讨论】：

您需要一个定义明确的对象图供 Breeze 使用。您可以使用 DbContext 来生成它，也可以在客户端生成它，但无论哪种方式，Breeze 都严重依赖它。如果您正在寻找的只是更改跟踪而不是对象图管理，我会考虑通过一些自定义 JS 实现更轻松的方法。

标签： entity-framework breeze n-tier-architecture

【解决方案1】：

退一步问问自己“客户端和服务器是如何通信的？”

如果客户端向服务器发送大量命令......“AddVisitor”、“UpdateVisitorAddress”、“GiveVisitorGoldStar”......那么你就有了一个消息传递范式。消息传递范式很好。我一点也不批评它。但 Breeze 对这种范式的支持并不特别好。

如果客户端主要执行 CRUD 操作——创建、读取（查询）、更新和删除......对实体类型，那么你就有了我所说的“实体范式”。 Breeze 对此有很好的支持。

我的感觉是，如果您在 SQL Server 前面使用由 EF 支持的 Web API ...您已经投资于实体范式。这些技术对实体范式的支持非常好，而对消息传递范式的支持则较差。

这个问题与在自己的层中有业务规则的 n 层后端完全不同。

DocCode example 展示了类似的分离。 Web API 位于“DocCode”项目中。模型层位于“DocCode.Models”项目中。而数据访问层在“DocCode.DataAccess.EF”层。

我们可以在模型项目中放置（也许应该放置）验证逻辑示例代码。它恰好位于数据访问项目中名为NorthwindEntitySaveGuard 的类中。在“现实世界”中，该类将是模型类本身中业务逻辑的调度程序。也有一些……但不多。

DocCode 也有一些“Dtos”的例子，在一些地方很方便。

所以...已经证明您可以在服务器上进行这种架构分离...我的问题是...您真正需要多少？有很多建筑 flim-flam 诱使我们过度设计事物。

我确实将我的 Web API 控制器与我的数据访问和模型定义分开。但我认为 DTO 舞蹈和层层叠加的意义不大。当然可以。我相当怀疑它是否有回报；它更有可能在我的经历中弄得一团糟。 YMMV。

【讨论】：