问题标签 [n-tier-architecture]

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

我们所针对的组织具有如下层次结构：公司 -> 集群 -> 业务部门 (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

我是一个使用 DAO 的自学 vb6 程序员。下面是我可以编写的一段典型代码的示例：

请假装上面是一个 CRUD 应用程序的完整源代码。我知道这种设计很糟糕，一切都混在一起了。理想情况下，它应该具有三个不同的层，用户界面、业务逻辑和数据访问。我有点明白为什么这是可取的，但我不知道它是如何完成的，我怀疑这就是为什么我不完全明白为什么这样的分离是好的。如果有人可以将上述可笑的微不足道的示例重构为 3 层，我想我会走得更远。

编辑：我正在使用 SqlDataAdapters 来填充数据集。抱歉——我应该更清楚。

我正在做一个项目，我需要用来自存储过程的信息填充许多强类型数据集。现在，我的数据访问层中有一个通用方法：

这样做的问题是我需要在存储过程返回的记录集和我的数据集中的表之间建立映射。为此，我提出了两种选择：

• FillDataSet向我的方法 ( )添加一个新的形式KeyValuePair<string, string>[] mappings，它将提供表映射的信息。
• 创建一个DataSetMappingFactory将 DataSet 作为参数的，然后根据其类型添加适当的映射。如果它是未知类型，则不会添加任何映射。然后，它将返回DataSet到该FillDataSet方法。

你们中有人对我如何解决这个问题有其他想法吗？此外，是否有人想权衡一种在面向对象设计方面最好的方法？

想知道我的方法是否可行或可以改进：

有这样的对象映射的想法吗？

我们有一个网站，可以在其中输入交易并通过工作流程。对于分层应用程序，我们将遵循标准 BLL（业务逻辑层）、DTO（数据传输对象）、DAL（数据访问层）等。我们需要将所有内容分开，因为某些事务将跨越具有不同业务逻辑的多个应用程序。

我们还有一个后端处理器。一旦工作流程完成，它就会处理我们的交易。它适用于各种第三方系统，其中一些不稳定，或者与它们的接口不稳定，然后报告交易状态。每个网站都有自己的后端处理器版本。

现在的问题是，对于 N 层，他们为每个应用程序建议一个新的 BLL。从上面的应用程序布局来看，后端处理器和网站可以说是一个应用程序一致行动，或者是两个具有不同业务逻辑的应用程序。处理这个问题的理想方法是什么？它像一个系统还是两个系统？

您如何管理由多个网站、桌面应用程序、Web 服务和混合了依赖项的数据库组成的 n 层系统的开发和部署？

假设您有一个具有源代码控制和自动构建的持续集成环境。

我最近看到很多开发人员的职位发布，其中包含一个或多或少这样的句子：“必须具有 N-Tier 架构的经验”或“必须能够开发 N-Tier 应用程序”。

这让我问，什么是 N-Tier 架构？一个人如何获得经验？

我需要在需要集中数据和文件存储系统（用于文档成像）但有多个分支机构且相互连接性相对较差的环境中部署 Delphi 应用程序。我相信 3 层数据库应用程序是最好的选择，这样我可以提供丰富的桌面体验和相对轻量级的数据传输需求。到目前为止，我已经简要介绍了 Delphi Datasnap、kbmMW 和 Remobjects SDK。似乎 kbmmW 和 Remobjects SDK 使用的带宽最少。有没有人有在具有大量用户（我需要支持 700+）的具有挑战性的环境中部署任何这些技术的经验？谢谢！

我们正在着手开发一项新的中间层服务，该服务将允许内部客户端系统在一些底层数据存储中创建、更新和查询记录。该服务将聚合多达 3 个独立的底层数据存储。出于这个问题的目的，假设：

数据存储#1：专有 XML 数据库。
数据存储#2：现成的关系数据库。
数据存储#3：平面文件存储（以二进制形式存储的文件）。

客户端将不知道（也不关心）他们正在查询/更新哪个数据存储。新服务将做出该决定。我的问题是：我的 API 应该公开 XML 还是对象？例如，新的 API 将有一个 add 方法。假设我们的系统是一个车载存储系统，那么API的add方法可能是这样的：

或者，它可能看起来像这样：

现在，即使第二个方法在入口处被弱类型化，XML 将立即根据模式进行验证，至少是。

新服务将用 C# 编写（尚未确定哪个版本，但可能是 WCF 的 3/3.5）。API 的客户端可以是 C#/VBA/VB.Net/C++/Java)。

任何更多细节请告诉我。谢谢

更新：请注意，API 还将通过消息总线发布 XML。例如，当添加新车时，将发布汽车 XML，以便任何对新车感兴趣的人都会收到通知。

我有一个针对 sqlserver DB 运行的 n 层 winform 客户端服务器应用程序。我希望它有时能够“离线”运行（未连接到数据库）并在重新连接时重新调整对主数据库的更改。现在，我要做出艰难的架构决定：我应该使用数据库复制还是使用队列/脚本等自己管理它。我的应用程序很复杂 - 我使用包含自动增量键和表之间的外键约束的表的数据库。我的部分数据没有像图片和文档那样嵌入到数据库中。非常想听听您的意见和过去的经验！谢谢，阿迪