设计 dapp
当您提出 dapp 的想法时，您将就如何构建和组织您的项目做出许多设计决策。 在 Internet Computer 上，您在规划应用实施时应特别注意一些设计决策。
注意:本节正在进行中且不完整。随着构建在 Internet Computer 上运行的 dapp 的最佳实践和设计模式不断发展，此处包含的信息也将相应地发展和变化。
单容器或多容器架构
在设计 dapp 时，您可能要考虑的首要决定之一是它应该封装在单个容器智能合约中还是由多个容器智能合约组成。
例如，如果您正在编写一个没有前端的简单服务，您可能希望使用单个容器来简化项目管理和维护，并专注于添加功能。 如果你的 dapp 同时拥有前端资产和后端业务逻辑，那么你的项目可能至少包含两个容器，一个容器用于管理用户界面组件，另一个容器用于应用程序提供的后端服务。
在规划中，您还可以考虑将一些常见的可重用服务放在它们自己的容器中，以便可以从其他更专业的容器中导入和调用它们，或者供其他开发人员使用。 LinkedUp 示例 dapp 通过将专业服务 dapp 拆分为两个容器来说明这种方法。 在 LinkedUp 示例中，建立社交关系的函数在“connectd”容器中定义，与用于设置在“linkedup”容器中定义的专业资料的函数分开。 很容易想象用第三个容器扩展 dapp，例如根据配置文件属性或共享连接安排事件。
将参与者从类型和实用程序中分离出来
在为您的项目规划架构时，一种常见的做法是将主要参与者的代码放在一个文件中，并带有单独的附加文件，用于定义您的程序使用的类型和不需要参与者的实用程序功能。
例如，您可以为 dapp 设置后端逻辑，使其包含以下文件:
-
Main.mo或main.rs具有需要参与者发送查询和更新调用的功能。 -
Util.mo或util.rs带有可以导入的辅助函数供actor使用。 -
Types.mo或types.rs包含 dapp 的所有数据类型定义。
使用查询调用
如链接中所述查询和更新方法，查询比更新调用更快地返回结果。因此，将函数显式标记为`query`是提高应用程序性能的有效策略。 在规划和设计阶段，您应该考虑如何最好地使用查询调用而不是可以执行查询或更新的函数。
这是一个很好的通用规则，可以广泛应用于大多数类别的 dapp。 但是，您还应该考虑查询不经过共识并且不会出现在区块链上的安全性和性能权衡。 对于某些 dapp，这种权衡可能是合适的。例如，如果您正在开发一个博客平台，检索与标签匹配的文章的查询可能不需要通过共识来确保大多数节点同意结果。 但是，如果您的 dapp 正在检索敏感信息（如财务数据），您可能需要比基本查询提供的更多保证。
作为基本查询的替代方案，Internet Computer 还支持*认证查询*。经过认证的查询使您能够接收最终用户可以信任的*经过身份验证的响应*。使用认证查询是教程或其他以开发人员为中心的文档中未涵盖的高级技术，但您可以了解认证的工作原理以及配置程序以返回认证数据以响应接口规范。