I think this question is really a variation to the question whether the bottom-up or top-down design is better. I find that it helps to do rough drafts of the front end to simulate typical usage of the site. This helps one to see required backend options one would have missed otherwise (thinking needed data).
我可能会在数据库级别提前计划，因为虽然对 HTML 的任何更改只会真正影响 HTML...数据库更改通常需要后端代码更改，而后端代码更改通常需要 HTML 更改，并且必须重做所有内容是痛苦的。
Especially when new people are working with project, I'd suggest an incremental approach.
Pick some functionality you know you're going to need. Start with the database (SQL), then the backend code (PHP, maybe), then the web frontend (HTML). Make it as simple as possible to accomplish that one block of functionality. The order of things doesn't matter as much as just taking a small chunk at a time to work on.
Once that small part works, save a copy. Version control, even. That way, you can always return to something that worked if you screw something up tomorrow.
Then pick the next small function and add it in. I always find this very motivating; you get to see consistent improvement.
I'd probably plan ahead on the database level, because while any change to the HTML only really affects the HTML... database changes often require backend code changes which often require HTML changes, and having to redo everything is painful.
You should architect the tiers that you expect to exist in the whole system. Each tier can be parallel architected/implemented by different people, however integration points will require collaboration to decide on the contract.
There are two general interface/contract patterns:
1) Consumer/Application Needs -> interface/contract is dictated by the application and the next tier is written to conform/adapt to those needs. All of the tiers are now essentially driven by their downstream consumers. The pro is that you will likely have the most efficient and limited set of methods required, the downside is there is more work to adapt the system to other consumers.
OR
2) Service Provider -> interface/contract is dictated by a service which is designed to support a core set of common functionality that may service many apps, even some yet to be known. The application that consumes the provider must then adapt the contract's capabilities with its internal needs. The pro is that the service is more re-usable without modification, however those generalized methods will likely be a less efficient fit for any particular app's needs.
Neither of these is the perfect answer, it depends on the situation. The decision of 1 or 2 above may also differ depending on which tier connection you are working on. You could have a service with a service contract #2, an app with its own needs contract #1, then an adapter tier that maps the apps needs to the service's functionality.
Regardless of which pattern you use, the architecture of your tiers, their contracts, and how they interact with each other is more important than when you start working on any particular tier.
In general once the tier design is in place, you work on the tiers where the contracts are defined and followup on the tiers where contracts are consumed.
The question is highly subjective. In the practical reality in which we live one is limited by the customer's ability to communicate their requirements in a such a way that they can be translated into code (and of course ever expanding requirements). Medium-Larger companies have Business Analysts to perform most of these duties. As far as which tier to start the design, a DB guy will say DB, webguy will say frontend, etc...to each in accordance to their abilities.
There's no silver bullet. I recommend you readup on a few major paradigms like Agile and waterfall.
发布评论
评论（5）
我通常首先决定前端需要哪些字段。
然后开始处理数据库后端......然后是带有单元测试的中间层......最后是前端。
当然，一旦我开始从事前端工作，我就会想到数据库的更多字段或更改......这就是开发的本质。
I usually decide what fields I need in the front end 1st.
Then start working on the database backend..then middle tiers with unit tests..then finally front end.
Of course, once I start work on the front end, I think of more fields or changes for the database....such is the nature of development.
我认为这个问题实际上是自下而上或自上而下设计更好的问题的变体。
我发现做前端的粗略草稿来模拟网站的典型用法很有帮助。这有助于人们看到否则会错过的所需后端选项（思考所需的数据）。
I think this question is really a variation to the question whether the bottom-up or top-down design is better.
I find that it helps to do rough drafts of the front end to simulate typical usage of the site. This helps one to see required backend options one would have missed otherwise (thinking needed data).
特别是当新人参与项目时，我建议采用增量方法。
选择一些您知道需要的功能。从数据库 (SQL) 开始，然后是后端代码（也许是 PHP），然后是 Web 前端 (HTML)。尽可能简单地完成这一功能块。事情的顺序并不重要，重要的是一次只处理一小部分。
一旦该小部分起作用，请保存一份副本。甚至还有版本控制。这样，即使你明天搞砸了某些事情，你也可以随时回到有效的事情上。
然后选择下一个小功能并将其添加进去。我总是觉得这非常激励人心；你会看到持续的进步。
我可能会在数据库级别提前计划，因为虽然对 HTML 的任何更改只会真正影响 HTML...数据库更改通常需要后端代码更改，而后端代码更改通常需要 HTML 更改，并且必须重做所有内容是痛苦的。
Especially when new people are working with project, I'd suggest an incremental approach.
Pick some functionality you know you're going to need. Start with the database (SQL), then the backend code (PHP, maybe), then the web frontend (HTML). Make it as simple as possible to accomplish that one block of functionality. The order of things doesn't matter as much as just taking a small chunk at a time to work on.
Once that small part works, save a copy. Version control, even. That way, you can always return to something that worked if you screw something up tomorrow.
Then pick the next small function and add it in. I always find this very motivating; you get to see consistent improvement.
I'd probably plan ahead on the database level, because while any change to the HTML only really affects the HTML... database changes often require backend code changes which often require HTML changes, and having to redo everything is painful.
您应该构建您期望存在于整个系统中的层。每个层都可以由不同的人并行架构/实施，但是集成点需要协作来决定合同。
有两种通用的接口/契约模式：
1）消费者/应用程序需求 ->接口/契约由应用程序决定，编写下一层是为了符合/适应这些需求。所有层级现在基本上都是由下游消费者驱动的。优点是您可能拥有所需的最有效且最有限的方法集，缺点是需要更多工作来使系统适应其他消费者。
或
2) 服务提供商 ->接口/契约由一项服务决定，该服务旨在支持一组核心通用功能，这些功能可以为许多应用程序（甚至一些尚不为人所知）提供服务。然后，使用提供者的应用程序必须根据其内部需求调整合约的功能。优点是该服务无需修改即可重用，但是这些通用方法可能不太适合任何特定应用程序的需求。
这些都不是完美的答案，这取决于具体情况。上述 1 或 2 的决定也可能会有所不同，具体取决于您所使用的层连接。您可以拥有一个带有服务契约 #2 的服务，一个具有自己的需求契约 #1 的应用程序，然后是一个将应用程序需求映射到服务功能的适配器层。
无论您使用哪种模式，各层的架构、它们的契约以及它们之间的交互方式都比您开始在任何特定层上工作时更重要。
一般来说，一旦层设计到位，您就可以在定义合同的层上工作，并在使用合同的层上进行后续工作。
You should architect the tiers that you expect to exist in the whole system. Each tier can be parallel architected/implemented by different people, however integration points will require collaboration to decide on the contract.
There are two general interface/contract patterns:
1) Consumer/Application Needs -> interface/contract is dictated by the application and the next tier is written to conform/adapt to those needs. All of the tiers are now essentially driven by their downstream consumers. The pro is that you will likely have the most efficient and limited set of methods required, the downside is there is more work to adapt the system to other consumers.
OR
2) Service Provider -> interface/contract is dictated by a service which is designed to support a core set of common functionality that may service many apps, even some yet to be known. The application that consumes the provider must then adapt the contract's capabilities with its internal needs. The pro is that the service is more re-usable without modification, however those generalized methods will likely be a less efficient fit for any particular app's needs.
Neither of these is the perfect answer, it depends on the situation. The decision of 1 or 2 above may also differ depending on which tier connection you are working on. You could have a service with a service contract #2, an app with its own needs contract #1, then an adapter tier that maps the apps needs to the service's functionality.
Regardless of which pattern you use, the architecture of your tiers, their contracts, and how they interact with each other is more important than when you start working on any particular tier.
In general once the tier design is in place, you work on the tiers where the contracts are defined and followup on the tiers where contracts are consumed.
这个问题是非常主观的。在我们生活的现实中，客户以一种可以将其转换为代码的方式传达其需求的能力受到限制（当然还有不断扩展的需求）。大中型公司有业务分析师来履行大部分职责。至于从哪一层开始设计，DB人员会说DB，WebGuy会说前端等等……根据每个人的能力。
没有灵丹妙药。我建议您阅读一些主要范例，例如 敏捷 和 瀑布。
The question is highly subjective. In the practical reality in which we live one is limited by the customer's ability to communicate their requirements in a such a way that they can be translated into code (and of course ever expanding requirements). Medium-Larger companies have Business Analysts to perform most of these duties. As far as which tier to start the design, a DB guy will say DB, webguy will say frontend, etc...to each in accordance to their abilities.
There's no silver bullet. I recommend you readup on a few major paradigms like Agile and waterfall.