【问题标题】:Confusion in designing an n-tier application [closed]设计 n 层应用程序时的困惑 [关闭]
【发布时间】:2013-11-08 17:09:30
【问题描述】:

我一直很难理解如何将我的程序分成具有 3 层(BLL、DAL、UI)的 n 层应用程序。我对这个主题有很多困惑,我不知道从哪里开始。我看过视频、文章和应用示例,但我觉得很难理解。从一个示例到下一个示例似乎缺乏一致性。有没有我可以查看的关于该主题的非常详尽的资源?

作为参考,我是一个C# .NET 入门级开发人员,现在这个话题是否太大而无法解决?我完全理解这个概念,但是我不知道如何很好地实现它。

【问题讨论】:

  • 这是一个非常广泛的话题。您是否有需要映射到此架构的特定问题?
  • 为了提供具体的答案,您要构建什么样的应用程序?哪个框架(ASP.Net、Silverlight、WPF...)?
  • 它将是一个 WPF 应用程序,无需使用服务即可与 SQL Server 数据库进行交互。
  • 可能值得先写它而不用任何层。然后,当您重新访问图层时,就会更清楚为什么它们会有所帮助。

标签: c# .net wpf n-tier-architecture


【解决方案1】:

对于初学者来说,最好考虑 3 层设计,但要知道在实践中它似乎层数多于 3 层。但从根本上说,有 3 层。

表示层

您构建的任何应用程序都会有某种表示层。它可能实际上是表示,或者它可能只是返回客户端期望的数据的层(例如,Web 服务响应、HTML/JavaScript 中的客户端 UI 等)通常你会有一些代表你的 的类客户端数据,通常称为 ViewModel 或仅称为 Presentation Model。这里的关键是数据特定于您呈现的视图。一个例子是一个订单历史表单,它只显示订单号、订单日期和总成本。在此特定视图中,您可能不需要知道用户名、每个订单项的成本、发货数量、税额、发货方式等。关于 ViewModel 应该如何工作以及它们是否必要存在很多争论。这仅取决于您的应用程序。关键是,如果您采用这种方法,ViewModel 只是轻量级的类,用于保存您的视图/页面使用的数据。

业务逻辑/领域层

这是通常可以分成几部分的层。它们可能包括以下内容:

  • 域对象或业务对象 - 这些是您的业务逻辑的对象表示。在领域驱动设计 (DDD) 和几乎任何其他编程范式中,这是您的业务对象应该驻留的地方。它们可能是代表客户、订单、帐户等的类。这里的关键是它们是您的数据的表示,在您的应用程序上下文中是有意义的。它们可能与您数据库中的数据不同,也可能与您向用户显示的数据不同,但在您的应用程序中,它们的结构是有意义的。
  • 存储库 - 这些是“集合”(我用引号表示,因为它们实际上可能不是集合),它们隐藏了数据层的复杂性并返回域对象的副本。这里的想法是,如果您需要一个 Order 对象,您可以向存储库请求它。例如,OrderRepository.FindByDateRange(startDate, endDate)。同样,这里的关键是您的业务层不应该直接访问数据;存储库掩盖了这种复杂性,还允许您更轻松地更改数据源,无论是数据库、xml、缓存等。
  • 助手或业务/域逻辑 - 这些通常是位于业务逻辑层中的类,它们执行特定于您的业务的事情。它们可能包括验证、计算、数据操作等。这里的关键是它们处理业务层数据并在在您的业务需求的上下文中对其执行操作。例如,您可能有业务需要确保所有订单至少有 3 个免费送货的订单项。这是一条业务规则,应该在您的业务层内执行。

数据层

数据层是与您的数据存储进行通信的实际代码。它可能是 ADO.NET 或对象关系映射器,如 Entity Framework、nHibernate 或其他。这是任何 SQL 或其他数据查询将驻留的地方(当然,T-SQL 应该尽可能多地在数据库中,但根据应用程序的类型,IMO 在这里可以原谅。)这里的关键是您的业务和演示层应该不知道数据实际来自何处,只知道它们以预期的格式接收数据。该数据层是返回该信息的内容。通常,数据层将查询数据存储并将数据放入某种类(有时称为数据实体或数据传输对象)。存储库使用这些来生成上述业务对象。

其他资源

例如,在上述层中,您可能还有一些映射类可以帮助从数据对象创建业务对象。像 AutoMapper 这样的项目可以帮助解决这个问题,尽管我承认我没有任何经验。

了解多态性和接口是个好主意。抽象对于这种层分离变得越来越重要。抽象可以让存储库从数据库或完全不同的源获取数据,但业务层不应该关心哪个。业务层需要的只是以预期的格式获取一些数据,它不应该关心从哪里来。我会认真考虑研究以下内容:SOLID 设计原则、设计模式(至少是存储库、适配器、工厂)、依赖倒置原则(不一定是控制反转框架或任何东西,至少在您了解依赖倒置原则之前)

请记住:

这是一个简化的示例,可能充满了错误信息和可以说是糟糕的设计,但希望有助于在您的脑海中稍微分离这些层。关于建筑有很多不同的观点,当归结为它时,我能给你的最佳答案是这真的取决于。通常分成我上面提到的部分会帮助你开始。听起来您有点像绿色开发人员,但不要气馁。您可以多年来每天花费数小时,并且永远不会对构建软件的方式完全满意。只关注有效的东西,并在有意义时进行重构。我一直在努力学习最好的方法,我已经阅读了几个月的文章,但仍然没有找到。

祝你好运。

【讨论】:

    【解决方案2】:

    你应该读这样的书

    Martin Fowler - Patterns of Enterprise Application Architecture

    Dino Esposito - Microsoft® .NET: Architecting Applications for the Enterprise

    但如果您是 C# 入门级开发人员(而不是同时不是高级 Java 开发人员 :)),它们可能太难了

    一些概述和基本的了解你可以得到here或搜索一些关于这个主题的简短易懂的文章。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-11-14
      • 2011-02-10
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-07-24
      相关资源
      最近更新 更多