将逻辑与表示分离：HTTP 变量名称？答案

【问题标题】：Separation of logic from presentation: HTTP variable names?将逻辑与表示分离：HTTP 变量名称？
【发布时间】：2010-06-08 07:00:38
【问题描述】：

这可能被认为是一个学术问题，而不是现实世界的问题 - 但把它扔出去看看是否有人有什么好主意！我们都知道，将应用程序的业务逻辑与演示文稿分开是一个好主意（我正在查看 web-apps atm），但需要了解业务逻辑之间的 HTTP 变量期望（以及然后处理）和表示层发送的变量名称。

这仅仅是告诉设计者在模板中使用什么变量名的问题吗？模板不需要知道变量名是什么（除非将它们用于 JS/CSS 选择器），那么为什么要在其中“硬编码”它们。或者业务逻辑是否应该将名称放入要打印的变量中？模板的另一层复杂性？

有没有人有这方面的经验，或者有如何处理的想法？

谢谢，艾伦

【问题讨论】：

【解决方案1】：

我的想法......我想这取决于开发人员。每当我构建应用程序时，我都会按照您的建议将业务和视图逻辑分开，并且通常会定义一个 ViewModel。 viewModel 然后成为业务逻辑和视图之间的契约。这允许两个团队（UI 和业务逻辑开发人员）独立开发，当然也可以轻松进行测试等。

我很欣赏有多种查看逻辑分离的方法，但是，根据经验，如果您可以在两者之间定义一个合约（采用哪种形式，取决于您使用的模式），它会使开发更容易，尤其是当您有独立的团队构建独立的组件。

【讨论】：

【解决方案2】：

当我以前从事网络开发工作时（目前我在管理/支持部门），问题是设计人员无法理解使用占位符的想法，这些占位符稍后会被替换 - 对于某些人来说复杂的布局（例如动态手风琴类型的分层导航菜单）在设计处理动画和功能与控制字体和颜色的样式表部分时存在先有鸡还是先有蛋的问题。

即使是最有能力的设计师，他们使用的工具也无法解决问题。

我们最终采用的方法是，开发人员将提供 HTML 片段的示例，然后设计人员将围绕这些示例构建页面，然后开发人员将用动态生成的内容替换片段并清理样式表，合并任何课程。

这是我们能找到的最务实的解决方案。

【讨论】：