【问题标题】:Three tier architecture三层架构
【发布时间】:2011-06-02 06:21:09
【问题描述】:

我对三层架构有一些疑问。

  1. 如何正确实现三层架构的应用程序?
  2. 如何在这些层之间进行通信?
  3. 数据层是否完全等同于 DBMS? (如果我们使用存储过程又如何呢?如果我们使用对象关系映射框架呢?)

期待听到您的回答。 谢谢。


PS:请不要理解我在问一个一般性问题。好的 ?我在问如何正确设计大型应用程序。什么是最好的方法?。不期待很长的答案。

【问题讨论】:

  • 你有时间读多少本书?
  • 投票结束。一般广泛问题的“我如何编程”风格不是stackoverflow的范围(太宽泛而无法得到好的答案)。阅读有关该主题的一些书籍,然后针对特定主题打开新问题-
  • 感谢您的回复。我知道在这里无法获得诸如“我如何编程”之类的问题的答案。有人可能会理解,这是一个普遍的问题。但事实并非如此。我在问具体的方法。具体概念。好的 ?如何在三层架构中设计大型应用程序?
  • 大喊大叫不会给你任何更好的答案。问题是,即使您专门询问最佳方式,问题是,一般意义上没有最佳方式,任何实现它的方式都有利弊,哪种解决方案适合您的项目取决于您的项目项目应该做什么以及每一层使用什么技术。

标签: c# 3-tier presentation-layer middle-tier data-layer


【解决方案1】:

这些是广泛的答案,我会尽力给你一些指示。

  1. “正确”是一个有点主观的术语。一般来说,我认为最重要的是将层保持在自己的模块中(例如,自己的 DLL),并有接口进出模块。通过在每一层中使用接口,您可以将定义与实现分开,从而进一步将各层相互解耦。如果该层只有一个入口点,并且它基于一个接口,那么您可以根据需要拥有多个底层实现。在另一个方向,如果你使用接口作为回调,那么层客户端(即其他层)将只需要实现接口以获得层之间的良好流动。

  2. 这取决于您如何实现层本身。如果您像我上面建议的那样设计层,您只需使用接口进出层。另一种解决方案可能是使其异步,使用事件调度器——一个层会简单地触发一个事件,而另一个层会监听这个事件并对其采取行动。这一切都取决于项目的具体要求。

  3. 不,数据层是应用程序中与 DBMS 交互的层。使用 ORM 只是一种实现数据层的方法,而使用存储过程是一种将一些逻辑从应用程序转移到 DBMS 本身的方法,原因有很多。

我猜你会收到几个答案;您应该将所有这些都考虑在内,通过网络进行一些阅读,并进行一些实验,直到找到您喜欢的内容。

【讨论】:

    【解决方案2】:
    1. 这三层是表示层、业务逻辑层和数据层。确保你不要混淆这些担忧。 UI 不应包含任何业务逻辑等。

    2. 任何层都应该只知道它下面的层。例如。 UI 应该只与业务逻辑通信,不应该知道任何关于数据层的事情。为了实现这一点,总是code to interfaces instead of concrete implementations。使用Dependency Injection 保持模块松散耦合。

    3. 这取决于您选择如何实现它。从YAGNI 校长开始。让事情尽可能简单,只有在您真正需要时才使用 ORM 之类的东西。

    【讨论】:

      【解决方案3】:

      这个话题太宽泛,无法正确回答这个问题所需的深度。也就是说:

      1. 一个关键是适当限制层之间的依赖关系,使每个层只知道“下面”的层。例如业务层不知道表示层。

      2. 三层架构没有规定各层之间如何通信。业务(层)功能经常公开为表示层使用的 Web 服务。

      3. 数据层不完全等于数据库。您总是需要一些代码来与数据存储交互(例如 ORM)。这段代码应该在它自己的模块中以最小化耦合。

      【讨论】:

        【解决方案4】:

        这取决于许多因素。我会考虑为您的数据访问层 (DAL) 使用存储库模式。理想情况下,这将与实体框架 4 或 nhibernate 之类的对象关系映射器 (ORM) 结合使用。然后,我将拥有一个单独的域层,其中包含业务规则和服务。您的域层将为您的 UI 和您的 DAL 之间的请求提供服务。对于您的 UI,您可以选择 Web 表单或 MVC 方法。两者仍将在三层内工作,但您将从 MVC 中获得更好的关注点分离。当您想要进行一些单元测试时,这很好。以下是关于上述内容的一些很好的链接。

        http://daveswersky.com/2010/05/26/entity-framework-4-then-and-now/

        http://channel9.msdn.com/blogs/matthijs/aspnet-mvc-2-basics-introduction-by-scott-hanselman

        http://www.asp.net/mvc/tutorials/mvc-music-store-part-1

        【讨论】:

          【解决方案5】:

          三层架构是一个概念,而不是一步一步的指导。保持简单和孤立。如果您正在处理数据存储和检索,请将其放在数据层中。当有逻辑需要时,将其放在逻辑/中间层。主题/皮肤、视图、小部件占位符进入表示层。

          研究别人的代码。一个好的起点是monoRail

          阅读大量文档,越了解其他人的做法越好。

          最重要的是,玩得开心。如果您感到不知所措或觉得事情变得复杂,请退后一步,找出问题所在。

          【讨论】:

            【解决方案6】:

            在 3 层架构中实现应用程序的最佳方式是使用使用 MVC 的语言框架。对于 PHP,我推荐 CodeIgniter http://codeigniter.com/

            如果遵循 OOP,通常会发生对象在三个级别之间的传递。嗯,主要是两个。控制获得请求,询问模型(DB)并获得一个对象作为回报,使用它的属性和方法来显示视图。

            按照 Ci 中的一些教程进行操作。您将了解 MVC 中发生的事情。

            【讨论】:

              【解决方案7】:

              三层架构分为三层,分别是表示层、业务逻辑层和数据访问层。除了这三个之外,我们还可以使用业务对象层来实现可以将我们的对象与数据库映射的属性类,或者您可以使用实体框架。

              表示层: 这是用户执行其活动的应用程序的最顶层。让我们以用户需要填写表格的任何应用程序为例。这种形式只不过是表示层。在 Windows 应用程序中,Windows 窗体是表示层,而在 Web 应用程序中,Web 窗体属于表示层。基本上用户的输入验证和规则处理都是在这一层完成的。

              业务层: 这是在表示层之上。顾名思义,大部分的业务操作都在这里进行。例如,在收集表单数据后,我们希望使用自定义业务规则对其进行验证。基本上我们在这一层定义类和业务实体。

              数据访问层: 业务逻辑层之上是数据访问层。它包含帮助业务层连接数据库并执行 CRUD 操作的方法。通常所有与数据库相关的代码和东西都属于数据访问层。有时人们使用独立于平台的数据访问层从不同的数据库供应商处获取数据。

              更多详情 - https://www.c-sharpcorner.com/UploadFile/dacca2/understand-3-tier-architecture-in-C-Sharp-net/

              【讨论】:

                猜你喜欢
                • 1970-01-01
                • 1970-01-01
                • 2012-02-27
                • 2014-03-07
                • 1970-01-01
                • 1970-01-01
                • 2023-03-25
                相关资源
                最近更新 更多