我们已经开始考虑使用 BreezeSharp，因为我们有一个 WebAPI ODATA 服务，我们想在 ASP.NET 网站上重新使用它（不涉及 javascript，只是纯 C#）。
不幸的是，我们刚刚注意到，根据文档，我们所有的模型实体现在都应该从 Breeze.Sharp.BaseEntity 继承。这对我们来说是不行的，因为这意味着在我们的商业模式中依赖 Breeze。我们宁愿只保留对 WebAPI 服务的依赖。
无论如何我们可以避免这种情况吗？例如，当它们不从 BaseEntity 继承时，在客户端有代理类？
对此有什么想法吗？
Breeze.Sharp.BaseEntity要求纯粹是在客户端，它的原因是提供所有的持久性、导航、键修复、更改跟踪和通知以及其他使微风客户端易于使用的服务。
Breeze.Sharp.BaseEntity 实现了一个IEntity接口，您可以自由地实现它而不是使用 Breeze.Sharp.BaseEntity，但是，这是一项非常重要的任务。如果我们的社区普遍认为这是可取的，我们正在考虑在以后提供一些指导。
我们还计划发布IEntity的 AOP 实现，可以直接在 POCO 模型对象之上注入，但这可能需要 PostSharp，并且在某些客户端平台（Android/IOS 的 Xamarin）上运行也可能存在问题。在我们了解需求之前，没有时间表。
另一方面，当前的实现非常尊重您的模型对象，只有一个“EntityAspect”属性与几个事件一起添加到您的模型中。
过去，我们在许多其他平台和应用程序库上尝试过纯 POCO 方法，发现缺点超过了基类的最低成本，特别是考虑到我们希望该库在任何 .NET 客户端（包括 Xamarin）中运行时/单核细胞增多症。
如果我理解正确，您唯一担心的是您不想在服务器模型中引用微风# 库。显然，您的客户端和服务器实体类的紧密耦合没有问题，因为它们具有相同的属性并且可能还具有共享方法。我不是在评判；我只是想确认你的架构决定。
您是否考虑过部分课程？
您在服务器端业务模型项目中定义不轻而易举的部分类，并在客户端模型项目中链接到该类源……您可以在其中保留具有客户端特定功能的伴随部分类。该客户端分部类文件指定了微风# 基类。
当您使用它时，您可以将仅服务器逻辑隔离在驻留在您的服务器项目中但不在您的客户端项目中的部分类文件中。
既然微软正在他们的“通用应用程序”愿景中推广 VS，这种源文件链接变得更加容易。