为什么HotTowel包含Breeze?

Mat*_*int 11 breeze hottowel

这听起来似乎是表面上的一个愚蠢的问题,但为什么Hot Towel SPA模板包括Breeze

过去几天我一直在学习Hot Towel及其依赖项,据我所知,模板中没有任何内容实际上使用Breeze.也许这会随着未来的发布而改变?

当然,Breeze是一个很好的图书馆.但它必须采用CRUD方法,并要求您以特定方式设计ApiControllers.(元数据,SaveChanges等)请看这里

它还指导您进入实体框架.虽然这更像是一种软依赖,但由于Breeze还展示了没有它的示例,它仍然使用修改后的存储库模式引导您使用类似的实现模式.

如果您使用NoSQL数据存储区或CQRS模式而不是CRUD,那么Breeze将变得非常难以使用.有一些替代的数据访问库可以很好地运用这种风格,例如AmplifyJS.

但热毛巾的其余部分非常棒!我特别喜欢Durandal.所以问题是,如果模板实际上没有进行任何数据访问 - 为什么要包含任何数据访问组件?最好是在没有Breeze的情况下运送它,如果最终用户想要使用Breeze,或者放大,或者其他什么 - 那就这样吧.Hot Towel的其余部分将继续作为一个伟大的SPA实施发光.

Joh*_*apa 18

马特 - 好问题.自从我创建它以后我想我应该回答:)

当我构建模板时,我专注于提供足够的东西,让人们使用正确的工具,并提供足够的入门代码来指导方向.我不希望任何人扯掉代码.我不是模板的粉丝,它会让你走上一条路,让你删除大量的文件和代码并改变方向.这些都是样品.

样品很好.事实上,样本可以很好(就像其他模板,我觉得更像样本).那些用于另一个目的:展示你如何做事.

回到Hot Towel模板...如果我包含使用Breeze的代码,我很想在客户端上添加datacontext.js和model.js.它们将包含数据访问代码和代码以扩展客户端上的模型.然后我会想要添加一个控制器,一些服务器端模型,一个ORM和一个数据库.在那里,我想在多个屏幕中使用数据,这导致我更多的Knockout和缓存与Breeze.然后我可能会想要添加编辑,这将导致更改跟踪.很快,我有一个完整的应用程序.或者更保守地说,我再次有一个样本.虽然这些方法可以提供更多关于如何将这些方法组合在一起的指导,但它们无法帮助您"开始"使用模板,您可以在其中开始构建和添加自己的代码.如果我没有完成其中的一些功能,它仍然走在一条需要你改变我的方式的道路上.

就目前而言,HotTowel非常接近真正意义上的模板.您创建一个新项目,然后您就可以添加自己的代码了.

您可以争辩(并且您可能会)Breeze不应该在那里因为我不在模板中使用它.我也不使用moment.js,BTW.但是,我认为它们都是优秀的库,我不想在没有它们的情况下构建基于CRUD的SPA.正如您所说,Breeze非常灵活,因此您无需走特定路径.

理解Breeze价值的最好方法是构建一个具有其功能但没有Breeze的应用程序.然后,您可以看到需要多少代码以及它涉及的代码.有一个这样的例子,请参阅我在Pluralsight的中级SPA课程,我正是这样做的:http://jpapa.me/spaps

所以你问"为什么微风?" ...因为我强烈推荐它建造SPA.

谢谢你的要求,祝你好运!

  • 作为旁注...放大,虽然很棒,但并不接近Breeze的作用. (2认同)
  • 谢谢你的详细解答.我想我使用Hot Towel更像样品启动器而不是模板.我看到了你的观点.对我来说,Breeze阻碍了我已经拥有一个丰富的WebAPI连接.对于其他人来说,也许它会更好.你在连接Durandal方面做得非常出色,而Hot Towel外壳非常清脆.我很容易更换我不想要的部件,所以这一切都很好.说真的 - 它给我带来了很多麻烦.谢谢!!! (2认同)

War*_*ard 7

谢谢你提问.

作为HT的作者,John提供了一个答案.我,作为Breeze项目的负责人,我倾向于同意他:)

HotTowel为您构建基础.它不是建筑本身.

它是一个基础,用于特定类型的应用程序,基于一组特定的协作JavaScript和ASP.NET技术的CRUD应用程序.微风是一个贡献者......但不是唯一的一个.Knockout凭借其MVVM设计和双向数据绑定,特别适合CRUD应用程序典型的数据输入任务.

当然还有其他种类的SPA.有一类重要的应用程序主要提供信息并且几乎不接受用户输入.这样的应用程序不会受益于数据绑定,并且编写它们的人可能会对数据绑定(尤其是KO)产生相当大的敌意.

我的观点是HT针对特定类别的应用程序......至少在通过持续受欢迎程度来衡量时,它恰好是非常成功的.它为构建这些应用程序的人员提供商品.它可能不适合其他类型的应用程序.

确实,Breeze的简单之路贯穿了Web API,EF和关系数据库.拿走那些,你可以在服务器上写更多的代码(以及客户端上的更多代码).这可能是您的完美权衡.

Breeze的作者希望让这条道路更容易.我不认为BreezeJS会让它变得更难.我不明白你的陈述" Breeze变得非常难以使用 ".你试过吗?

您的客户端可以以您选择的任何方式与任何HTTP资源进行通信.使用现有的Web API控制器非常简单(尽管使用Breeze Web API控制器更容易).如果你愿意,你可以使用amplify.js(顺便说一下,你可以告诉Breeze用放大器进行AJAX调用).如果您不想,您甚至不必使用Breeze EntityManager查询和保存数据.

BreezeJS的其余部分可能仍然对您有价值.在弄清楚如何检索和存储数据以及是否更喜欢Entity-ChangeSet样式或Command/Query样式之后,还有很多工作要做.

你必须找到这些问题的答案:

  • 您将如何将原始JSON数据整形为可绑定对象?
  • 您将如何保持这些对象并在多个屏幕上共享它们,而无需多次往返服务器?
  • 如何将Address绑定到StatesAndProvinces的组合框时,如何从一个对象导航到相关对象?
  • 您将如何跟踪变化?
  • 你将如何验证它们?
  • 当应用程序"墓碑"时,您将如何将部分或全部数据存储在本地存储中?

即使您不希望它为您查询和保存,Breeze也可以帮助您完成这些杂务.

如果你的回答仍然是" 我会自己完成所有这些,谢谢 "......好吧,从你的HotTowel项目中删除Breeze就像这样简单:

Uninstall-Package breeze.webapi

  • 另一点 - 我希望能够使用相同的WebAPI端点来构建我自己的应用程序,并为我的客户提供开发人员SDK以连接到我的后端服务器.我的应用程序不应该有任何特殊访问权限,我也不想强迫其他人使用微风.他们可能完全在其他平台上.也许有一些调和的模式我没想过? (6认同)
  • 我很想看到Breeze示例与一些现有的Web API控制器绑定...也许Matt和Ward可以一起看看.看到结果会很有趣. (5认同)
  • 我听得很清楚.当我对这些问题发出一些内部关注时,请继续进行自己的调查.我知道你并不孤单. (3认同)