请坚持我，因为这个问题可能很长！我们目前正在设计和制作我工作的基于Web的应用程序的原型。这是一个大型应用程序，具有很多复杂性和复杂性以及大量数据。
在前端技术方面，我们将使用Durandal，Knockout和TypeScript（编写所有JavaScript和jQuery代码）构建SPA。
后端已经过非常仔细的考虑和设计。简化后，我们将提供一套应用程序服务（使用nHibernate，AutoFac等），它们将使用经过精心设计的域模型。然后，WebAPI将使用应用程序服务中的方法将数据呈现回前端。
构建具有大量DB交互作用的SPA时，一个显而易见的想法是考虑Breeze。 Breeze出色的原因有很多，有据可查。问题是，我们不确定它是否适合我们的体系结构。除了简单的原型，我们没有人使用Breeze，所以如果有人可以帮助回答以下问题，我们将不胜感激！
1-我们是否假设默认情况下使用Breeze会绕过我们的业务逻辑并直接转到nHibernate或数据库，这是否正确？如果这个假设是正确的，是否有办法绕过它？有什么建议/链接吗？我们的想法是，我们必须为Breeze写一个适配器，以路由到我们的业务逻辑，并将元数据提供回Breeze。然后，这会带来其他问题，例如在系统的不同部分中具有部分和完全水合的模型，投射外键。对我们来说这是一个有争议的问题！
2-使用TypeScript的众多原因之一是为我们提供具有智能感知的静态类型对象。我们是否假设我们使用Breeze是否正确就可以了？
3-我们根本不需要任何缓存。是否可以完全关闭Breeze的这一部分？
4-如果我们不使用查询功能（我们绝对没有，我们有一个搜索计划，这意味着不能选择使用Breeze查询功能），那么我们就不使用缓存功能，我们可以将东西放到位（例如T4模板，以从DTO自动生成TypeScript对象），以帮助加快开发速度并减少Breeze允许的代码，我们是否反对使用Breeze？
我已经做了很多搜索，但是我能找到的就是为什么要使用Breeze。虽然我承认这太棒了，但从目前为止的理解来看，我只是不确定它是否适合我们的应用程序。任何建议或推荐的阅读将不胜感激。随着Breeze在现场的出现，我正努力寻找更多信息！
最佳答案
1）您可以拦截任何查询或保存在服务器上的Breeze中。对于保存，这是通过ContextProvider上的BeforeSaveEntities和BeforeSaveEntity可重写方法完成的。对于查询，只需在服务器端端点方法中通过自定义代码即可完成。 Breeze文档中描述了这两种技术，并且Breeze zip中的DocCode示例中有示例。
2）我们的客户使用Breeze和Typescript，并使用Breeze元数据生成Typescript类定义。我们计划在以后提供这种代码的版本以供一般使用。 （我们目前为Typescript相关任务提供咨询支持。请通过[email protected]与我们联系。）
3）我们计划在一个月内为下一个版本的Breeze提供noTracking选项。当前，可以仅通过执行“投影”查询来重现相同的效果。
4）在Breeze中使用您自己的查询系统没有问题。请参阅Breeze文档中有关“ namedQuery”的讨论。如果您想通过其他客户端过滤来扩展基本查询的位置，甚至可以混合搭配。
到更大的点。如果您不打算使用任何缓存或任何轻巧的查询增强功能，那么Breeze可能不是一个很好的选择。
但是，缓存的价值是您真正需要评估的东西。如果您打算进行以下操作，则可能需要自己重新创建此功能。
以断开连接的方式运行您的应用程序。这包括从本地存储进行序列化和反序列化。
减少客户端和服务器之间已获取数据的往返次数。随着应用程序变得更大，这可能是其性能的重大改进。
能够查询当前计算机上的内存中的内容。
分别检索时，自动关联彼此相关的实体的图。
更改跟踪以及将实体还原到其原始查询状态的能力。
还有其他一些问题，我有点懒得枚举。
希望这可以帮助！
关于c# - Breeze 在SPA体系结构中的适用性问题，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/19703554/