【问题标题】:Is loose coupling possible for a web app?Web 应用程序可以松散耦合吗?
【发布时间】:2012-02-27 14:26:36
【问题描述】:

我理解内容、表示和行为应该是分开的,通过使用 HTML、CSS 和 JS 来独立实现它们。在动态 Web 应用程序中保持松散耦合的同时具体绑定这些元素是否有最佳实践?甚至可能吗?最好不依赖 jQuery?

澄清我在说什么:HTML 没有定义新标签的机制,因此当您的 JavaScript 模型需要生成内容时,其表示的标签和结构必须在 JS 中定义或以某种方式使其可访问它,将行为与内容紧密耦合。

在有人调用 over-OOP 之前,我希望将标签和 CSS 类保留在 JS 之外的原因是我什至不想将 HTML 作为前端提交。我最终需要的底层模型至少有五种不同的表示形式,并且将模型与 HTML 紧密耦合至少排除了其中两种。

有什么方法可以在不牺牲动态或松耦合的情况下将模型后期绑定到目标表示?像一个 XML 文档对应模型元素到模板 HTML sn-ps?

更新

虽然提供有关因式分解和 OO 最佳实践的问题的具体细节似乎落后了,但我想提供一个更新鲜的例子来说明 HTML 固有的形式和功能的纠缠。问题在于 HTML 和 JS 之间的内容和行为的纠缠,而不是示例,我想要一个在更改细节时不会中断的答案。它来自一个与我第一次问这个问题时正在工作的项目完全不同的项目,但要点是相同的:

  • 我有一些用于 UI 小部件的 HTML。它是一个向用户表示模型对象(调色板的选择)的视图。调色板本身是应用任务的一部分,因此它们不是视图,而是模型。

  • 我想在至少 2 个不同的对话框中使用这个小部件(以及我将来可能想要的任何对话框)。一方面,我需要更改选择以立即采取行动,即对属于同一对话框的画布元素中的一组图像重新着色。在另一种情况下,我只需要从两个不同的集合中进行选择 - 每个集合中的一个选项。

  • 我不想复制和粘贴此小部件的 HTML 表单或 JS 行为,因为我希望维护和修订从一个基本事物传播到它的所有实例。因此,我的源代码中可能只存在一个小部件实例,无论其形式如何。

  • 我不想让我的 JS 直接渲染 HTML 标签,因为这样做会失去我的 IDE 对 HTML 的错误检查和内容帮助。此外,如果 HTML 输出有问题,它们在我的 JS 中的来源将不太清楚,因为生成 HTML 的过程看起来不像 HTML,也不一定反映其结构。最后,我想独立于我的 JS 来测试小部件的 CSS 和 HTML 更改的效果。

  • 我不想涉及其他依赖项,例如在我的源代码中分离模板和参数化语言,因为对各种标准的更改或不断变化的需求可能会破坏它们的兼容性,或者它们本身可能在未来变得无人维护,给我留下大量无用的源代码。依赖 jQuery 是可以的,因为它对浏览器之间的规范化(更不用说方便)所做的工作比鉴于其无处不在而可能会破坏的功能更多,但其他库将被视为极端怀疑。

  • 我想在仅引用小部件及其组件的 JS 中指定更改和检索小部件状态的详细信息(调色板由哪些颜色组成,用户如何选择),因为它将是以不同方式使用其信息的多个对话框的一部分。

  • 1234563修复错误等。

为了简单地制作小部件的 HTML 的多个副本,我可以选择在 HTML 文件中存在的模板节点上调用 jquery.clone,并从设置对话框的函数中将内容插入到我需要的位置。当任何被克隆的元素具有idname 属性时,HTML 会使事情变得困难,但是在克隆期间小心处理可以生成唯一标识符,将它们对应的label 元素和href 属性指向新的标识符,并保留旧的可在数据属性中访问。所以对于结构和内容来说一切都很好,很明显,CSS 演示文稿可以很好地传播到克隆。

当我尝试使用其对话框的控制器实现小部件的界面时,问题就来了。暴露小部件状态抽象的最面向未来的方法是什么? IE。我不想使用widgetJquery.find('input:checked').val() 从代码中获取选定的颜色,该代码不一定必须提交基于已检查输入元素的选择,该输入元素的 value 属性是一组序列化颜色。

我希望这样可以更清楚地说明我在寻找什么,而不会用细节混淆问题。

【问题讨论】:

  • 只是好奇:您还会将 JS 用于哪些非 HTML 前端?关于你关于不依赖 jQuery 的评论,我喜欢 jQuery,但请注意它是用 JS 编写的,所以它不能做任何你自己无法在 JS 中手动编码的事情......
  • @nnnnnn IDE 集成文档和交换格式是我想要的非 HTML 表示。它们用于将相同的模型展示给非常不同的用户集。
  • 你能在你的问题中准确解释你在做什么吗?可能还有其他方法可以解决,而不是接近你真正想要的。让我们敞开心扉。

标签: javascript html css xml oop


【解决方案1】:

您始终可以让不同的 XSLT 解析 XML。
但是,您似乎尝试抽象太多。
使用MVC,使用不同的视图来解析。

您所写的方法在旧系统中很常见,我在 10 多年前就使用过,进化杀死它可能是有充分理由的。

【讨论】:

  • 您能否更具体地说明您认为我所关心的哪一方面不切实际?哪个紧耦合不值得避免?我绝不是 OO 大师,我只是想在具体步骤中实现我的想法,而不是以后踢自己。
【解决方案2】:

使用设计模式在架构上最好地实现松散耦合。 Mediator Pattern 中有一个很好的例子来说明如何实现松耦合。但是,有几种模式可供使用。

我建议阅读 Addy Osmani 的 'Essential JavaScript design Patterns' 以全面了解各种模式。

享受吧!

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-06-05
    • 2012-02-18
    • 1970-01-01
    • 2020-10-26
    • 2011-02-22
    • 1970-01-01
    相关资源
    最近更新 更多