Web 应用程序的最佳工作流程是什么？
我即将开始一个网络应用程序。在开始之前，我想获得一些关于创建此类 Web 应用程序的最佳工作流程/顺序的建议。
我的项目将包含一个带有 PHP 和 MySQL 的服务器端。客户端将是 XHtml、CSS 和 jQuery。还会用到AJAX。
我确信这取决于某些情况，但是总的来说，使用这些凭据开发项目的最佳顺序是什么？
我应该先开始开发服务器端吗？或者我应该从客户端开始？或者我应该同时做这两件事？数据库怎么样——这应该是首要任务吗？那么也许是 DAO？
I am about to begin a web application. Before I begin, I would like to get some advice as to what the best work flow/order is for creating a web application such as this.
My project will consist of a server-side with PHP and MySQL. The client-side will be XHtml, CSS and jQuery. There will also be AJAX used.
I'm sure that it can depend on certain situations, but, overall, what is the best order for developing a project with these credentials?
Should I start developing the server-side first? Or should I begin with the client-side? Or should I do both at the same time? What about the database - should that be a first priority? Then perhaps the DAOs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先从数据开始。服务器端数据是应用程序持久的、重要的核心。如果这个数据模型不正确，你就一无所有。
您应该能够对数据模型进行单元测试，以证明您具有正确的属性和关系。这不需要太多。一些用于插入、更新和查询的测试用例。
您将通过后端处理支持该数据模型。
这也应该进行单元测试，以证明它可以工作并且可以对您的数据模型执行所有正确的操作。这会稍微复杂一些，因为此处理是应用程序。
然后您可以考虑 Web 服务向 Ajax 公开的数据模型。
这也是可测试的，以证明 JSON 做了正确的事情。此测试通常相当复杂，因为这是 GUI 前端所依赖的。这一定是对的。
然后，一旦制定了 Ajax 数据模型，您就可以编写前端 GUI。
Start with the data first. The server-side data is the persistent, essential core of the application. If this data model isn't right, you have nothing.
You should be able to unit test the data model to prove that you have the right attributes and relationships. This doesn't require much. A few test cases to insert, update and query.
You will support that data model with back-end processing.
This, too, should be unit tested to demonstrate that it works and does all the right things to your data model. This will be a bit more complex, since this processing is the application.
Then you can think about the data model as exposed by web services to Ajax.
This, also, is testable to prove that the JSON does the right things. This testing is often fairly complex because this is what the GUI front-end relies on. This has to be right.
Then, once you have that Ajax data model worked out, you can write the front-end GUI.
您所描述的工作流程是我用于我自己的（个人）项目的工作流程。
我喜欢在中间见面。我首先进行数据建模，同时开始设计界面原型。业务规则排在最后，它将所有内容整合在一起。
当我有一个 GUI 可供查看时，我还发现它“鼓舞人心”...它鼓励我让它做一些事情。此外，GUI 往往会经历最多的修改，因此在流程中尽早开始它们可以确保您对最终产品感到满意，并且在实现业务逻辑时它会最终确定。
The workflow you're describing is what I use for my own (solo) projects.
I like to meet in the middle. I do data modeling first, and simultaneously start prototyping the interface. Business rules come last and pull everything together.
I also find it "inspiring" when I have a GUI to look at... it encourages me to make it do something. Furthermore, GUI's tend to undergo the most revising, so starting them early in the process ensures you'll be happy with the finished product, and that it'll be finalized by the time your business logic is implemented.
如果我在一家大公司工作，但不确定他们到底想要什么，我会首先从用户界面开始。这样，在我将大量时间投入到系统的其余部分之前，他们就可以弄清楚他们想要什么。
另一方面，如果我确切地知道需要什么，那么我将从一个功能开始，然后逐步通过各层、数据库、控制器、视图和 ajax，直到完成该功能，然后继续进行下一个功能。这样我就可以记住更少的上下文，而客户总是有新的东西可以玩。
If I'm working for a big company that's not sure of exactly what they want, I'll start with the UI first. This way they get to figure out what they want before I've put a lot of time into the rest of the system.
On the other hand, if I know exactly what is needed, then I will start with one feature and work my way up through the layers, database, controller, view, and ajax, until that feature is done, and then go on to the next feature. This way I've got less context to remember, and the client always has something new to play with.
我无法告诉您什么绝对是最好的，但对我来说最有效的是...
与业务人员交谈，了解他们想要什么。
用笔和纸绘制 UI。方框代表页面。按钮和链接有指向其他页面的箭头。不需要每一个微观细节。有些东西是隐含的。
一旦 UI 设计得很好，就可以设计数据库模式。有时我会像这样在文本文件中写出所有表...
然后实现数据库。我使用 Rails 迁移。您可以手动编写 DDL。
如果您有模型或 DAO 或类似的东西，我接下来会通过单元测试来实现它们。
如果您有模型或 DAO 或类似的东西，
然后我通常逐个实体地处理应用程序实体。让视图和控制器正常工作。在测试代码和实现代码之间快速切换。
这是一般的顺序，但整个过程中都会有调整等等。您需要返回数据库设计并在构建实际功能时对其进行改进。
I can't tell you what's absolutely best, but what works for me is...
Talk to the business people to get an idea of what they want.
Draw the UI with pen and paper. Boxes represent pages. Buttons and links have arrows pointing to other pages. Don't need every microscopic detail. Some things are implicit.
Once the UI is mapped out pretty well, design the DB schema. Sometimes I'll write out all the tables in a text file like this...
Then implement the database. I use Rails migrations. You might write the DDL manually.
If you have models or DAOs or something along those lines I would implement those next, with unit tests.
Then I usually work through the app entity by entity. Get the view and controllers working. Rapidly switching between the testing code and the implementation code.
That's the general sequence, but the whole time there are adjustments and so on. You'll need to go back to your DB design and evolve that as you build the actual functionality.