1

我对使用今天发布的新 EntityErrorsException 非常感兴趣。但是我的同事实现服务器端逻辑的方式可能是个问题。

在 webAPI 控制器中，我们使用了自己的 contextProvider，它继承自微风的 EFContextProvider。请参见下面的代码：

 public class SepaContextProvider : EFContextProvider<CompanyName.BLL.BLDirectDebitContext>
 {
    public MyContextProvider() : base() { }
 }

如您所见，通用参数是一个 BLDirectDebitContext，它继承自数据访问层中定义的 DirectDebitContext 类：

 public class DirectDebitContext : DbContext{
 }

这样，通过覆盖 ValidateEntity() 在 BLDirectDebitContext 类中验证实体，因此如果从桌面应用程序（不使用 webAPI 甚至轻而易举）调用此代码，则不必重新编写验证逻辑.

理想情况下，我们可以在这里创建 EFEntityError 对象并抛出 EntityErrorsException。但这意味着在我们的业务层中引用breeze.webapi dll，考虑到依赖项的数量，这听起来不太好。

将微风.webapi dll 拆分为不同的 dll 不是更有意义吗？还是我们的方法没有任何意义？

4

1 回答 1

2

我们计划在不久的将来将 Breeze.WebApi 重构为至少两个或三个 dll。（抱歉，还没有确切的日期）。一个包含核心 .NET 通用代码（依赖项大大减少），另一个是特定于实体框架的代码。我们计划同时发布一个 NHibernate 特定的 dll，与实体框架版本并行。

当然，这将是一个突破性的变化，这就是为什么我们要努力让一切井井有条，这样我们就不必再这样做了。理想情况下，对于任何 Breeze 消费者来说，从当前结构到新结构的转换都相当容易。

在一个稍微相关的问题上，您是否注意到您还可以使用标准的 .NET DataAnnotation Validation 属性以及 EntityErrorsException。这两种机制导致完全相同的客户端体验。

于 2013-07-23T17:58:31.917 回答