breeze:为什么要继承Breeze.Sharp.BaseEntity？

Question

我们已经开始考虑使用BreezeSharp，因为我们有一个WebAPI ODATA服务，我们想在ASP.NET站点上重用它(不涉及javascript，只需要纯C#)。

不幸的是，我们刚刚注意到，根据文档，我们所有的模型实体现在都应该继承自Breeze.Sharp.BaseEntity。这对我们来说是行不通的，因为这意味着在我们的业务模式中需要依赖Breeze。我们宁愿将这种依赖仅保留在WebAPI服务上。

有没有什么办法可以避免这种情况呢？在客户端拥有代理类，例如，当它们不是从BaseEntity继承的时候？

对此有什么想法吗？

Answer 1

Breeze.Sharp.BaseEntity实现了一个IEntity接口，您可以自由地实现它，而不是使用Breeze.Sharp.BaseEntity，然而，这是一项非常重要的任务。如果我们的社区普遍认为这是可取的，我们正在考虑在以后的日期提供一些指导。

我们还计划发布IEntity的AOP实现，它可以直接注入到POCO模型对象之上，但这可能需要PostSharp，而且在一些客户端平台上运行也可能会有问题(适用于安卓/IOS的Xamarin)。在我们了解需求之前，没有时间框架。

另一方面，当前的实现非常尊重你的模型对象，只有一个'EntityAspect‘属性和几个事件一起添加到你的模型中。

我们在过去尝试过纯POCO方法，在许多其他平台和应用程序库上，我们发现它的缺点超过了基类的最小成本，特别是当我们想要这个库在任何.NET客户端上运行时。

Answer 2

如果我理解正确的话，您唯一关心的问题是您不想在服务器模型中引用breeze#库。显然，您的客户端和服务器实体类的紧密耦合没有问题，因为它们具有相同的属性，也许还有共享的方法。我不是在评判；我只是想确认您的架构决策。

你有没有考虑过分部类？

您可以在服务器端业务模型项目中定义没有微风的分部类，在客户端模型项目中定义 to that class source ...您可以在其中保留附带的分部类和特定于客户端的功能。该客户端分部类文件指定了breeze#基类。

在此过程中，可以在部分类文件中隔离仅服务器逻辑，这些文件驻留在服务器项目中，而不是客户端项目中。

这样的源文件链接在VS中已经变得更容易了，因为微软正在他们的愿景中推广它。