我们已经开始考虑使用BreezeSharp了，因为我们有一个WebAPI ODATA服务，我们想要重新使用ASP.NET站点（不涉及JavaScript，只需要纯C＃）。
不幸的是，我们只是注意到，根据文档，我们所有的模型实体现在应该继承自Breeze.Sharp.BaseEntity。这对我们来说是不合适的，因为这意味着在我们的商业模式中依赖Breeze。我们宁愿仅依赖于WebAPI服务。
无论如何我们可以避免这种情况吗？在客户端有代理类，例如当他们没有从BaseEntity继承？
对此有何想法？
答案 0 :(得分：1)
Breeze.Sharp.BaseEntity 要求纯粹是在客户端，其原因是提供所有持久性，导航，密钥修正，更改跟踪和通知等服务使微风客户端如此易于使用。
Breeze.Sharp.BaseEntity实现了一个 IEntity 接口，您可以自由地实现它而不是使用Breeze.Sharp.BaseEntity，但是，这是一项非常重要的任务。如果我们的社区普遍认为可取，我们正考虑在以后提供一些指导。
我们还计划发布可直接在POCO模型对象上注入的 IEntity 的AOP实现，但这可能需要PostSharp，并且可能在某些客户端平台上运行时也会出现问题（适用于Android / IOS的Xamarin）。在我们了解需求之前，没有时间框架。
另一方面，当前的实现非常尊重您的模型对象，只有一个＆＃39; EntityAspect＆＃39;属性已添加到您的模型中以及多个事件。
我们过去在许多其他平台和应用程序库中尝试过纯POCO方法，并且发现缺点超过了基类的最低成本，特别是考虑到我们希望这个库在任何.NET中运行时客户包括Xamarin / Mono。
答案 1 :(得分：1)
如果我理解正确，您唯一关心的是您不想在服务器模型中引用breeze＃libraries。显然，您对客户端和服务器实体类的紧密耦合没有任何问题，因为它们具有相同的属性，也可能是共享方法。我不是在评判;我只是想确认你的架构决策。
您是否考虑过 部分课程 ？
您可以在服务器端业务模型项目中定义部分类，而在客户端模型项目中定义link to that class source ...您可以在其中保留具有客户端特定功能的随播部分类。该客户端部分类文件指定了breeze #base class。
当您使用它时，您可以在驻留在服务器项目中但不在客户端项目中的部分类文件中隔离仅服务器逻辑。
现在，微软正在推动它"Universal apps"的愿景，这样的源文件链接变得更加容易。