【问题标题】:Software Design - Three-tier architecture软件设计 - 三层架构
【发布时间】:2011-08-16 18:10:57
【问题描述】:

第 3 层 - 界面

第 2 层 - 业务逻辑(从用户获取输入,检查是否有效,发送到数据库功能)

第 1 层 - 数据库(创建、更新、获取记录等)


一个用户可以添加多个联系电话号码,如果是第一个添加的电话号码,系统会自动将该电话号码设置为主要电话号码,之后用户可以自行更改其主要电话号码。

当在数据库中创建第一条电话号码记录时,哪个层负责检查电话号码是否需要设置为主?

【问题讨论】:

  • 它非常简单,并且作为业务逻辑(从用户获取输入,检查是否有效,发送到数据库功能)意味着它,所以我认为,您的业务逻辑应该在添加电话号码时处理它给用户。因为数据库只是为了存储数据,接口只是为了和用户交互,业务层只做决策。

标签: c# asp.net design-patterns architecture


【解决方案1】:

当电话号码被添加给用户时,您的业务逻辑应该处理它。您可以通过为其提供单元/集成测试来验证它是否有效。

【讨论】:

    【解决方案2】:

    业务层。数据库应该存储数据,而不是做出决策。界面只是与用户交互。业务层制定规则。

    【讨论】:

      【解决方案3】:

      N 层应用程序中的数据层实际上不应该做任何事情,只是将值放入和获取值。将其视为持久性服务。

      除了 UI 代码(在遵循 MVP、MVC 或 MVVM 之类的内容时,您应该将这些东西分开),其他所有内容都进入所谓的业务和/或逻辑层。

      虽然这个简单的问题实际上引发了事务问题,但您的数据模型最终应该可以防止这种情况发生,但是如果您不能以原子单元的形式完成操作,那么总是有可能同时输入两个电话号码并且它们都最终成为主要的(取决于应用程序和数据库之间的延迟)。要优雅地处理这些情况,您至少需要考虑以有意义的方式传播这些问题的错误恢复(错误处理)。不要只是让您的应用程序崩溃。

      【讨论】:

        【解决方案4】:

        我想这取决于您的目标。因为它是您的业务层,所以应该处理手机被验证/设置为主要。数据库仍然需要以我认为的某种方式存储该信息。

        但是,在某些情况下,例如安全验证,您需要在接口、逻辑和数据库级别进行一些检查。是的,这是多余的,但我认为您需要保证破坏您的界面或逻辑的黑客不会到处乱搞您的基础数据。

        【讨论】:

        • 最好的解决方案是一次性定义所有业务规则,并为 UI 和数据库层使用一些代码生成工具。
        【解决方案5】:

        除了上述答案之外,您可能需要考虑保留输入而不管其有效性。可以增加一点开发(特别是如果您需要清理数据),但根据您的应用程序可能值得

        【讨论】: