逻辑与表示分离：HTTP 变量名称？
这可能被认为是一个学术问题，而不是一个现实世界的问题 - 但把它扔出去看看是否有人有任何好主意！我们都知道，将应用程序的业务逻辑与表示分离是一个好主意（我正在查看 web-apps atm），但是需要在业务逻辑之间了解期望的 HTTP 变量（以及然后处理）和表示层发送的变量名。
这只是告诉设计者在模板中使用哪些变量名称的问题吗？模板不需要知道变量名是什么（除非将它们用于 JS/CSS 选择器），那么为什么要在其中“硬编码”它们呢。或者业务逻辑应该将名称放入要打印的变量中？模板的另一层复杂性？
有没有人有这方面的经验，或者关于如何处理它的想法？
谢谢， 艾伦
This could probably be considered an academic question, rather than a real world one - but throwing it out to see if anyone has any great ideas! We all know that keeping the business logic of an application separate from the presentation is a good idea (I'm looking at web-apps atm), but there needs to be an understanding between the business logic for what HTTP variables to expect (and then process) and the variable names which are sent by the presentation layer.
Is this simply a matter of telling the designer what variable names to use in a template? The template doesn't need to know what the variable names are (unless using them for JS/CSS selectors), so why should they be 'hardcoded' in there. Or should the business logic put the names into variables to be printed out? Another layer of complexity for the templates?
Does anyone have any experience of this, or thoughts on how to deal with it?
Thanks,
Allan
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我的想法......我想这取决于开发商。每当我构建应用程序时，我都会按照您的建议将业务逻辑和视图逻辑分开，并且通常定义一个 ViewModel。然后，viewModel 就成为业务逻辑和视图之间的契约。这允许两个团队（UI 和业务逻辑开发人员）独立开发，当然也允许轻松测试等。
我很欣赏有多种方法来查看逻辑分离，但是，通过经验，如果您可以在两者之间定义一个契约（无论哪种方法）它所采取的形式取决于您使用的模式）它使开发更容易，特别是当您有单独的团队构建单独的组件时。
My thoughts ... I guess it depends on the developer. Whenever I build apps, I , as you suggested, seperate the business and view logic, and usualy define a ViewModel. The viewModel then becomes the contract between business logic and the view. This allows both teams (UI and business logic developers) to develop independantly and of course allows easy testing etc..
I appreciate there are various approaches to view logic seperation, but, through experience if you can define a contract bewteen the two (in whichver form it takes depending on what pattern you are using) it makes development easier, especially when you have seperate teams building sperate components.
当我以前从事网络开发工作时（目前我在管理/支持部门），问题是设计师无法理解使用占位符的想法，这些占位符稍后会被替换 - 对于一些复杂的布局（例如，动态手风琴类型的分层导航菜单）在设计处理动画和功能与控制字体和颜色的样式表部分时存在先有鸡还是先有蛋的问题。
即使是最有能力的设计师，他们使用的工具也无法解决问题。
我们最终采用的方法是，开发人员将提供 HTML 片段的示例，然后设计人员将围绕这些片段构建页面，然后开发人员将用动态生成的内容替换片段并清理样式表，合并所有类。
这是我们能达成的最务实的解决方案。
C.
When I'd previously worked in web-development (currently I'm in admin/support) the problem was that the designers couldn't get their heads around the idea of using placeholders which would be substituted later - and for some complex layouts (e.g. a dynamic accordion type hierarchical navigation menu) there was a chicken and egg problem around designing the parts of the stylesheets which handled animation and functionality vs controlling fonts and colours.
Even with the most capable of designers, the tools they use don't lend themselves to solving the problem.
The approach we ended up taking was that the developers would provide examples of HTML fragments which the designers would then build the pages around, and then the developers would replace the fragments with the dynamically generated content and clean up the style sheets, merging any classes.
It was the most pragmatic solution we could arrive at.
C.