对于大多数网络开发大师来说，我的问题听起来很愚蠢，但作为新手，我想问一下我是否可以开发前端并且只在后端之后开发？
另外，如果我需要数据库，我应该先设计它吗？
我也想知道项目的分析部分。一位朋友简短地告诉我，开始项目需求分析（内部、技术和设计）是必须的。假设我想建立一个能够让用户注册的社交电子商务网站。你能确定一个编号列表你会做什么来准备这样的项目的分析（等1.数据库设计a）准备数据模型......）
如果有人能提供一个彻底的答案，我会很高兴。
谢谢你。
问候，唐尼
问问题
16552 次
5 回答
13
我通常决定我需要在前端 1st 中的哪些字段。
然后开始在数据库后端工作..然后是带有单元测试的中间层..最后是前端。
当然，一旦我开始做前端工作，我就会想到更多的领域或数据库的变化……这就是开发的本质。
于 2010-07-07T20:02:04.607 回答
9
我认为这个问题实际上是自下而上或自上而下设计更好的问题的变体。我发现它有助于做前端的草稿来模拟网站的典型使用。这有助于人们查看否则会错过的所需后端选项（考虑需要的数据）。
于 2010-07-07T20:25:18.240 回答
5
尤其是当新人正在处理项目时，我建议采用增量方法。
选择一些你知道你会需要的功能。从数据库（SQL）开始，然后是后端代码（也许是 PHP），然后是 Web 前端（HTML）。使完成这一功能块的过程尽可能简单。事情的顺序并不重要，只需要一次处理一小部分。
一旦该小部分起作用，请保存一份副本。版本控制，甚至。这样一来，如果你明天搞砸了，你总能回到原来的工作上。
然后选择下一个小功能并添加它。我总是觉得这很激励；你会看到持续的改进。
我可能会在数据库级别提前计划，因为虽然对 HTML 的任何更改只会真正影响 HTML……数据库更改通常需要后端代码更改，而后端代码更改通常需要 HTML 更改，并且必须重做所有事情是痛苦的。
于 2010-07-07T20:02:36.057 回答
1
您应该构建您期望存在于整个系统中的层。每一层都可以由不同的人并行架构/实现，但是集成点将需要协作来决定合同。
有两种通用的接口/合约模式：
1) 消费者/应用程序需求 -> 接口/合同由应用程序决定，编写下一层以符合/适应这些需求。现在，所有层级基本上都由其下游消费者驱动。优点是您可能需要最有效和有限的一组方法，缺点是需要做更多工作才能使系统适应其他消费者。
或者
2) 服务提供者 -> 接口/契约由一个服务决定，该服务旨在支持一组核心的通用功能，这些功能可以服务于许多应用程序，甚至一些应用程序尚不为人所知。然后，使用提供者的应用程序必须根据其内部需求调整合约的功能。优点是该服务无需修改即可更易于重用，但是这些通用方法可能不太适合任何特定应用程序的需求。
这些都不是完美的答案，这取决于情况。上述 1 或 2 的决定也可能会有所不同，具体取决于您正在处理的层级连接。您可以拥有一个服务合同 #2 的服务，一个应用程序拥有自己的需求合同 #1，然后是一个适配器层，将应用程序需求映射到服务的功能。
无论您使用哪种模式，层的架构、它们的合约以及它们之间的交互方式都比您开始在任何特定层上工作时更重要。
通常，一旦层级设计到位，您将在定义合同的层级上工作，并在使用合同的层级上进行跟进。
于 2010-07-07T20:05:24.010 回答