问题标签 [n-tier-architecture]

我对我的公司很陌生（2 周），我们正在使用 DotNetNuke 的 .NET 3.5 Team Foundation 为我们的系统启动一个新平台。我们的“建筑师”建议我们使用一个类项目。当然，我回想一下“三层”架构（业务、数据、Web 类项目）。

使用这种架构有什么缺点吗？专业人士将代码与数据分离，使类对象远离您的代码等。

我正在与一位同事“讨论”在新应用程序中实现数据层的最佳方式。

一种观点是数据层应该知道业务对象（我们自己的代表实体的类），并且能够在本地使用该对象。

相反的观点是数据层应该与对象无关，并且纯粹处理简单的数据类型（字符串、布尔值、日期等）。

我可以看到这两种方法都可能有效，但我自己的观点是我更喜欢前者。这样，如果数据存储介质发生变化，业务层就不必（必然）改变以适应新的数据层。因此，从 SQL 数据存储更改为序列化的 xml 文件系统存储将是一件微不足道的事情。

我同事的观点是，数据层不应该知道对象定义，只要数据传递得当，这就足够了。

现在，我知道这是有可能引发一场宗教战争的问题之一，但我希望社区提供任何关于您如何处理此类事情的反馈。

TIA

我目前正在从 UI 编写一个 ASP.Net 应用程序。我正在实现一个 MVP 架构，因为我厌倦了 Winforms，并且想要更好地分离关注点的东西。

因此，对于 MVP，Presenter 处理 View 引发的事件。这是我用来处理用户创建的一些代码：

我使用内置的 .Net 验证控件完成了主要表单验证，但现在我需要验证数据是否充分满足服务层的标准。

假设可以显示以下服务层消息：

• 电子邮件帐户已存在（失败）
• 输入的引用用户不存在（失败）
• 密码长度超过数据存储允许的长度（失败）
• 成员创建成功（成功）

我们还假设 UI 无法预期的服务层中将有更多规则。

目前，如果事情没有按计划进行，我会让服务层抛出异常。这是一个足够的策略吗？这段代码对你们来说有味道吗？如果我写了一个这样的服务层，你会不会因为必须编写以这种方式使用它的 Presenter 而感到恼火？返回代码似乎太老套了，布尔值不够丰富。

不由 OP 编辑​​：合并由 OP 作为答案发布的后续评论

Cheekysoft，我喜欢 ServiceLayerException 的概念。对于我没有预料到的异常，我已经有了一个全局异常模块。您是否觉得让所有这些自定义异常变得乏味？我在想捕获基本异常类有点臭，但不确定从那里进展如何。

tgmdbm，我喜欢那里巧妙地使用 lambda 表达式！

感谢 Cheekysoft 的跟进。因此，如果您不介意在未处理异常的情况下将用户显示为单独的页面（我主要是 Web 开发人员），那么我猜这将是策略。

但是，如果我想在用户提交导致错误的数据的同一视图中返回错误消息，那么我必须在 Presenter 中捕获异常？

以下是 Presenter 处理 ServiceLayerException 时 CreateUserView 的样子：

对于这种错误，最好将其报告给同一个视图。

无论如何，我认为我们现在超出了我原来的问题的范围。我会玩弄你发布的内容，如果我需要更多详细信息，我会发布一个新问题。

现在LINQtoSQL稍微成熟了一点，我想知道人们使用该技术创建n 层解决方案的任何技术，因为这对我来说似乎并不那么明显。

假设您正在实现一个用户故事，该用户故事需要在从 UI（或服务外观）到 DB 的所有层中进行更改。

你往哪个方向移动？

• 从 UI 到业务层到存储库到数据库？
• 从数据库到存储库到业务层到 UI？
• 这取决于。（什么 ？）

在我刚刚完成的项目中，我正在努力让分布式事务正常工作。

我们使用 JBoss 的 Arjuna 事务管理器和 Spring 的声明性事务边界来实现这一点。

我们的请求序列如下所示：

这意味着我们有一个 WAR 服务于我们的安全 servlet 和一个 EAR 服务于我们的 SLSB。

我们的 SLSB 有一个静态初始化块来引导我们的 Spring 应用程序上下文。

我不喜欢技术的混合，但我喜欢表示层和业务层的分离，它们可以驻留在不同的物理位置。

我很想知道其他人在使用 Spring 时建议将层分开吗？

我正在做的项目是使用 n 层架构。我们的层如下：

• 数据访问
• 商业逻辑
• 商业实体
• 介绍

Business Logic 向下调用到数据访问层，Presentation 层向下调用到 Business Logic 层，业务实体都被它们引用。

我们的业务实体与我们的数据模型 1-1 基本匹配。对于每张桌子，我们都有一个班级。最初设计框架时，没有考虑管理主从关系或子父关系。所以所有的业务逻辑、数据访问和业务实体，都只引用了数据库中的一个表。一旦我们开始开发应用程序，很快就会发现在我们的对象模型中没有这些关系会严重伤害我们。

您的所有层（包括数据库）都是从内部元数据数据库生成的，我们用它来驱动我们自己开发的代码生成器。

问题是在我们的实体中加载或延迟加载关系的最佳方式是什么。例如，假设我们有一个与地址表具有主子关系的人员类。这在业务实体中显示为 Person 对象上 Addresses 的集合属性。如果我们有一对一的关系，那么这将显示为单个实体属性。填充和保存关系对象的最佳方法是什么？我们的业务实体不了解业务逻辑层，因此在调用属性 get 时无法在内部完成。

我敢肯定有某种标准模式可以做到这一点。有什么建议么？

此外，需要注意的一点是 DataAcess 层使用反射来构建我们的实体。存储过程基于一张表返回一个结果选择，并使用反射通过将属性名称与列名称匹配来填充我们的业务对象。所以做连接会很困难。

我们的客户想知道谁在线并且当前正在使用我们为他们编写的自定义应用程序。我和他们讨论过，这不需要很准确，更多的猜测会起作用。

所以我的想法是确定用户活动的 15 分钟时间间隔。我这样做的一些想法如下：

1. 每次他们执行访问数据库或请求网页的操作时，用他们上次活动的日期和时间标记他们的用户记录......虽然这可能是数据库密集型的。

2. 从我们的软件发送“谁在线请求”，寻找响应，这可以在预定的时间间隔内完成，然后在用户记录上标记我收到的每个响应的当前日期和时间。

你怎么认为？您将如何处理这种情况？

澄清

如果可能的话，我想为 Windows 或 Web 使用相同的架构。我有一个与多个用户界面交互的业务逻辑层，可以是 Windows 或 Web。

通过Windows，我的意思是客户端-服务器。

澄清

我使用的是 n 层架构，因此我的业务对象处理与表示层的所有交互。该表示层可以提供客户端-服务器 Windows 应用程序、Web 应用程序、Web 服务等。

它不是一个高流量的应用程序，因为它是为我们的一个客户开发的，最多可能有 100 个用户。

我环顾四周，看到了一些很棒的代码片段，用于定义规则、验证、业务对象（实体）等，但我不得不承认，我从未见过完整的优秀且编写良好的业务层。

我只知道我不喜欢什么，但不知道什么是伟大的。

谁能指出一些好的 OO 业务层（或出色的业务对象），或者让我知道他们如何判断业务层以及是什么让一个业务层变得出色？

谢谢

我们正在为客户设计工资单生成系统。

我们所针对的组织具有如下层次结构：公司 -> 集群 -> 业务部门 (BU) -> 部门 -> 员工

员工的工资由各种工资组成部分组成。每个工资组件都有 3 个与之关联的规则，一个计算规则（将组件计算为另一个组件的百分比，或一个固定数字或固定数字的百分比），一个资格规则（员工/部门是否有资格获得一个组件）和限制组件的最大值和最小值的约束规则。

这些规则是可编辑的，并且可以由用户最终用户进行编辑。这些规则也是自上而下继承的，但如果在较低级别定义，则较低级别的规则优先。

我们有一个包含出勤、休假、奖金表的数据库，这些规则也应该与这些表交互。

客户将为多个客户生成工资单，每个客户都托管一个单独的数据库实例。它们可能对每个组件都有不同的解释，并且可能具有不同的组件。

我们只希望支持 SQL Server，工资单生成将是一项离线活动。

我们对将使用这些规则生成各个税收组成部分（包括税收减免、税收核销、免税额等）的逻辑放在哪里存在分歧。

有些人提倡神奇的 SP，它将获取员工 ID 并生成当月的工资单。其他人希望将逻辑拆分为单独的组件，这些组件将在应用层获取员工的相关数据并在那里计算这些组件。

我们的优先顺序是： 1. 快速适应新客户变化的能力 2. 长期可维护性 3. 性能

1 和 2 在这里比 3 重要得多，因为这将是一个离线活动。

可维护性和快速可定制性非常重要，我们将为不同的客户部署应用程序。客户 A 的薪资构成规则可能为 ((0.3 * Basic) + 800)，客户 B 可能有 (0.2 * Basic) + (0.1 * Atendance Bonus)

SP 是否会在这里造成混乱，因为上面建议的规则将由最终用户指定，并且需要通过 Web UI 进行自定义。我们将不得不从 SQL 中解析公式。会有多难或容易？与使用 SP 相比，在应用层 (C# .Net) 中执行此操作有什么优势？

对现有系统架构的建议和指示将非常有帮助。...是的，我们在系统的其他地方使用 LINQ to SQL。

亲切的问候， Ashish Sharma