最终 Web 开发框架的功能要求？

发布于 2024-08-11 05:58:18 字数 1408 浏览 4 评论 0原文

可用的 Web 开发框架多种多样，似乎总是有“尝试新事物”的永恒动力。因此，我们中的一些人发现自己正在用一种框架交换另一种框架，但对最终结果永远不会完全满意。当然，总会有一些特定的 Web 框架能够完美地发挥作用。但是，有许多人决定使用 C++、Java 或 C# 来构建桌面应用程序等。对于 Web 开发应用程序而言，情况并非如此。 Joel Spolsky 在链接文本中谈到了这一点。

假设我要构建这样一个框架：功能需求是什么？这里的目标是列出具体功能期望（当然是为了 stackoverflow 发布而简洁定义的）。最佳答案将根据得票数选出。

为了让大家开始，以下是部分要求列表。请注意，这些项目故意保留了一些抽象性，以便人们可以从中派生出更具体的项目：

OOP 一致性：服务器端和客户端模块之间的无缝数据交换和本机对象表示：也就是说，给定一个客户端函数：clientFoo() 和一个服务器端函数：serverFoo()，应该能够传递一个任何类型 T 的对象 obj，无需任何编组：
```
定义 clientFoo() {
    T obj = createObject()
    服务器Foo(对象)
}

或者

定义 serverFoo() {
    T obj = createObject()
    clientFoo(对象)
}
```

这增加了本地对象表示在客户端和服务器端必须相同的要求，包括所有组合、类间耦合和封装语义。基本上，给定的类或给定的实例是否驻留在客户端或服务器端应该完全无关。

功能一致性：无缝功能和线程执行：人们应该能够在客户端/服务器端创建一个函数并将其传递到边界执行。这包括对多线程的统一支持（应该在客户端和服务器端一致地工作）。
- 多应用程序会话互操作性：这里的一个完美示例是应用程序间“剪切和粘贴”（如上面指出的文章中所述）。我并不是在谈论将浏览器中的文本简单地复制到另一个浏览器实例（或选项卡）。如果想将 MySocialApp 中的联系人对象粘贴到 YetAnotherSocialApp 该怎么办？这种应用程序间的数据交换很重要。
- 一致的跨浏览器兼容 UI：创建 AJAX“对话框”、进度指示器、选项卡等都应该可以使用与框架其余部分无缝连接的 API 来实现正如上面讨论的客户端/服务器集成。哦，是的，它必须在所有浏览器上都以相同的方式工作（开发人员完全看不到浏览器的区别）。

原文

With the wide variety of web development frameworks that are available, there always seems to be a perpetual incentive to "try something new". Hence, some of us find ourselves trading one framework for another, never being entirely satisfied with the end results. Granted there will always be niches where a given web framework will serve perfectly. But, there are many who have settled on using C++, Java or C# for building, say, desktop applications. The same isn't quite true when it comes to web development applications. Joel Spolsky touches on this in link text.

Let's say if I were to build such a framework: what would the functional requirements be? The goal here is to list concrete functional expectations (defined succinctly for the sake of a stackoverflow posting, of course). The best answer will be chosen based on its number of votes.

Just to get everyone started, the following would is a partial list of requirements. Note, these items were intentionally left somewhat abstract with the intent that folks can derive more concrete items from them:

OOP Consistency: Seamless data exchange and native object representation between server-side and client-side modules: That is, given a function on the client-side: clientFoo() and a function on the server-side: serverFoo() one should be able to pass an object obj of any type T without requiring any marshalling:
```
define clientFoo() {
    T obj = createObject()
    serverFoo(obj)
}

OR

define serverFoo() {
    T obj = createObject()
    clientFoo(obj)
}
```

This adds the requirement that native object representations must be the same on both the client and server side, including all composition, inter-class coupling, and encapsulation semantics. Basically, it should be entirely irrelevant whether a given class or a given instance resides on the client-side or the server-side.

Functional Consistency: Seamless functional and thread execution: One should be able to create a function on the client/server side and pass it over the boundary for execution. This includes uniform support for multi-threading (which should work consistently on both the client and server sides).
- Multiple Application Session Interoperability: A perfect example here is inter-application "cut and paste" (as mentioned in the article pointed out above). I am not talking about trivial copying of text within the browser to another browser instance (or tab). What if one wants to paste say, a contact object in MySocialApp to YetAnotherSocialApp? This kind of inter-application data exchange is important.
- Consistent cross-Browser compatible UI: creating AJAX "dialog boxes", progress indicators, tabs, etc should all be achievable using an API that is as seamless with the rest of the framework as the client/server integration discussed above. Oh, and yes, it has to work the same on all browsers (with browser distinctions being completely invisible to the developer).

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

迟月 2024-08-18 05:58:18

就我个人而言，我认为下一个伟大的 Web 开发框架本质上将是“函数式”的，即它将使用函数式语言，并且所有视图、控制器等都将是函数式的等价物。我们已经通过 Linq 朝着这个方向前进。

请参阅 Paul Graham 的击败平均水平，其中描述了他如何通过使用 Lisp 构建 Web 应用程序来超越竞争对手：http://www.paulgraham.com/avg.html

回复收藏 0 原文

蓝眸 2024-08-18 05:58:18

你错过了重要的部分。

将显示逻辑与代码分离。
将数据（发布的内容）与代码库分离。
能够在任何地方运行
框架的维护有多积极。

所以你需要输出模板，无论它是 xml 还是 html 等。
简单的模型视图控制器结构很方便
一个良好的数据库抽象层，允许您模板化 SQL，并阻止 SQL 注入。
占地面积轻。
在许多不同的网络平台上运行的能力。（最好是非专有的）例如：Apache (PHP)
可跨多个服务器扩展：（会话维护等）
易于扩展。
受社区欢迎。

跨浏览器兼容性很大程度上取决于您选择的 css、html 和 ajax 库...这与您的 Web 开发框架完全不同。你最好不要重新发明轮子。建议选择一个 javascript 库。（例如 Jquery）

一种维护应用程序中的内容并仍然允许将代码存储在存储库中的方法，并在开发/测试/和生产版本上进行更改/推出。通常内容会在框架中混合在一起，并且很难维持开发并继续发布内容。内容和代码的分离非常重要。