用自定义库包装jQuery,dojo?

Tom*_*ker 4 javascript

来自Java,我想知道Java最佳实践是否适用于JavaScript.

在Java中,接口和实现是分离的,将它们混合起来被认为是一种不好的做法.出于同样的原因,建议从最终开发人员隐藏库的实现细节.

例如,log4J是最受欢迎的日志库之一,但建议将代码写入slf4j库或"包装"log4j的Commons Logging库.这样,如果您选择切换到另一个日志记录框架(如logback),则可以在不更改代码的情况下执行此操作.另一个原因是,作为日志库的用户,只要您知道日志记录的作用,您就不会担心如何进行日志记录.

回到JavaScript,大多数非平凡的Web应用程序都有自己的自定义JavaScript库,其中许多使用开源库,如jQuery和dojo.如果自定义库依赖于jQuery,而不是作为扩展,而是作为实现,您是否认为需要添加另一个包装jQuery的层并使其对其余JavaScript代码透明?

例如,如果你有包含所有自定义前端逻辑的foo库,你将引入刚刚包装jQuery的bar库.这样,你的foo库就会使用bar库来实现jQuery函数,但它完全没有jQuery.从理论上讲,您可以切换到其他库,如dojo和google web toolkit,而不会对foo库产生太大影响.

你觉得这有什么实际价值吗?矫枉过正?

Dem*_*cht 15

虽然从理论的角度来看它是有道理的,但在实践中我会说它太过分了.如果出于以下两个原因,没有别的:

  1. 任何增加请求大小(或添加更多请求)的东西都是不好的 - 在网络世界中,少即是多.
  2. 如果你正在使用说jQuery,那么你切换到Mootools这样的东西的机会很小(imho).从我所看到的,顶级库每个都旨在解决不同的问题(至少在Mootools和jQuery的情况下 - 请参阅这个伟大的文档获取更多信息).如果你试图实现一个可以在两者之间轻松切换的中间件库,我认为你会遇到很大的麻烦.


Car*_*osZ 6

根据我的经验,我自己也是一名Java开发人员,有时候我们倾向于将整个"抽象"层模式过分考虑,我已经看到过某些人为了"灵活性"而决定完全抽象某个框架的实现,但它结束了使事情变得更复杂并创建更多代码来维护.

底线是您应该根据具体情况来看待它,例如,您不会尝试在struts之上或JPA之上创建一个抽象层,以防万一然后转到另一个框架(我很少见过.)

我的建议是,无论您使用何种框架,创建在内部使用框架的对象和组件,他们都应该为您的问题建模并能够在它们之间进行交互,而无需任何特定的框架.

希望这可以帮助.


Ben*_*son 5

这里有很多好的答案,但我没有看到的一件事就是功能集.如果您尝试编写一个库来包装jQuery提供的功能,但是您希望能够轻松换出类似原型的东西,则会遇到问题.jQuery库没有提供原型提供的所有功能,而原型也没有提供jQuery提供的所有功能.最重要的是,它们都以完全不同的方式提供它们的功能(原型扩展了基础对象 - 这几乎不可能包装).

最后,如果您尝试将这些库包装在一些代码中,这些代码添加了"抽象"以试图使它们更加灵活,那么您将失去80%的框架所提供的内容.你将失去他们提供的花哨界面(jQuery提供了一个很棒的$('选择器')函数,原型扩展了基础对象),你还必须决定是否要省略功能.如果两个框架都没有提供给定的功能,则必须抛弃它或为其他框架重新实现它.这是一大堆蠕虫.

整个问题源于Java是一种非常不灵活的语言.库提供了功能,就是这样.在JavaScript中,语言本身非常灵活,可以让你做很多疯狂的事情(比如编写一个库,然后将它分配给$变量).做疯狂事情的​​能力让javascript库的开发人员提供了一些非常有创意的功能,但这意味着你不仅可以在库中找到共性并编写抽象.我认为编写好的JavaScript需要对Java开发人员进行重大改进.