我对使用今天发行版随附的新EntityErrorsException非常感兴趣。但是我的同事实现服务器端逻辑的方式可能是一个问题。
在webAPI控制器中，我们使用自己的contextProvider，它从breeze的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，考虑到依赖项的数量，听起来不太好。
将breeze.webapi dll分为不同的dll会更有意义吗？还是我们的方法没有任何意义？
最佳答案
我们计划在不久的将来将Breeze.WebApi重构为至少两个或三个dll。 （对不起，没有确切的日期）。一个包含核心.NET通用代码（依赖性大大降低），另一个包含特定于Entity Framework的代码。我们计划与Entity Framework版本同时发布NHibernate特定的dll。
当然，这将是一个巨大的变化，这就是为什么我们试图正确地组织一切，而不必再次这样做。理想情况下，对于任何Breeze消费者而言，从当前结构到新结构的转换都将非常容易。
在一个稍微相关的问题上，您是否注意到您还可以使用标准的.NET DataAnnotation验证属性以及EntityErrorsException。这两种机制导致完全相同的客户端体验。
关于javascript - breezejs:新的EntityErrorsException，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/17814516/