问题标签 [3-tier]

我正在编写一个设计文档，我团队中的人愿意从 ASP.NET WebForm 迁移到 ASP.NET MVC。这很好，但我很难理解 MVC 如何在 3 层（数据层、业务层和表示层）架构中工作。我们可以说模型、视图和控制器是表示层的一部分吗？模型是业务层的一部分吗？

简而言之，MVC 和 3 层架构如何协同工作？谢谢您的帮助！

感谢您花时间阅读这个问题。

我正在设计一个用 c# 编写的 3 层解决方案，需要每分钟执行一次处理。应该从程序的不同未连接部分同时启动处理。

实现系统范围计时器的最佳方法是什么？应该在业务逻辑层还是UI层？哪种计时器最好，例如 System.Forms 或 System.Threading 中的计时器，还是？这种情况有经验法则吗？

非常感谢

我目前正处于（非常）小型数据库应用程序的研究阶段。

这是一个本地慈善机构，它只有 3 或 4 台将运行系统的客户端机器 - 但是为了将一些无关逻辑从客户端移开，我倾向于使用三层架构（有数据是在适当的时候不断通读和更新，客户不需要知道）

即客户端<->服务器逻辑<->数据库

虽然我能够胜任 Java 本身和一些框架/库，但我并不特别熟悉哪些框架可以帮助我。显然我将使用 JDBC 作为数据库的一半，但客户端和服务器之间的通信是目前的绊脚石 - 例如，我真的不想去靠近原始套接字的任何地方（矫枉过正，或者至少是另一个解决方案必须存在）

我已经询问了一些我知道的开发人员对使用哪些 API 的看法，虽然他们非常有帮助，但我仍然不太确定该去哪里。到目前为止，我已经听说过 RESTful 的东西、SOAP、COBRA 和一大堆其他技术。SOAP 是引起我注意的主要问题（因为有一些很好的例子可以将它与普通应用程序一起使用，而不仅仅是在网络上），但我仍然不确定该去哪里——它似乎并不特别适合一般应用程序像这样的目的应用程序（EJB 也出现了，但我听到很多针对它的仇恨 - 这是应得的吗？）

感觉好像为了找到“工作的最佳工具”，我实际上需要完整地学习每一个工具以“获得”它们（这显然是不切实际的）

任何人都可以指导我如何选择这样的 API（当我以前没有使用过它们时）或者给我一些常见的信息，或者这真的只是一个试验大量它们以查看哪些适合的案例最好的？

或者也许我完全错过了标记并且有一个针对这种确切情况而没有明显缺点的框架？

非常感谢您的帮助。

编辑：

完全忘记提及它实际上做了什么：它并不是非常复杂——慈善机构运行一个运输计划，所以它保存了司机、客户、司机里程记录等的详细信息，以供查看和编辑。唯一真正复杂的是驱动器，因为可以将驱动程序分配给可以预见的“永远”持续的重复（持续）驱动器。但是正在进行的驱动器的每个实例都必须是唯一的，因为它们可以单独取消或编辑

我选择 3 层的主要原因是因为作为一个慈善机构（有许多不太“精明”的老年志愿计算机用户），我很可能会经常更新 UI 以消除错误和不“对新手用户来说非常清楚。所以我的计划是首先让服务器和数据库之间的后端绝对“防弹”，然后将我所有的注意力集中在 UI 上，这样我就可以继续开发和迭代它而不用担心后端（也是因为我将远程开发它的一部分，将更新集中在客户端稍微简单一些）

所有这些属性都可能大喊“做一个基于 Web 的系统”——这里的障碍是，它们与已经运行的一些应用程序进行了各种棘手的集成，我不相信我可以（正确地）完成网络应用程序。

我有一个相对较小的项目，我使用的是 3 层架构。现在我正在考虑如何将一些函数拆分到不同的数据类中。

例如，我有一个 User 类和一个 Group 类。我的 User 类有一个 User.GetGroups 函数，我的 Group 类有一个 Group.GetUsers 函数。我会将第一个放在 UserData 类中作为 UserData.GetGroups 还是放在 GroupData.GetGroupsForUser 中，或者可能是一个完全独立的 UserGoupData 类？

在我的公司，他们终于（大约是时候......）考虑将我们最畅销的应用程序之一从 2 层架构转换为 3 层架构，无论是在逻辑层（表示层、业务层和数据层）还是物理层。可能我们会选择 Delphi-Delphi-Oracle 或 Delphi-Java-Oracle 方法来进行更改。

这是一个相对较旧且较大的应用程序，在我开始在那里工作之前已经创建和修改了很长时间。除非必须更改某些内容，否则通常不会考虑重构。此外，业务逻辑存在于两个实际层中......叹息。

物理变化并没有给我带来太多困扰，但逻辑变化将是一种穿越地狱的通道。为了尽可能地平滑它，我想研究哪些 Delphi 组件更适合 3 层模型。

¿ 您会考虑使用哪些替代方案？

我的应用程序中有这些层：

• 实体
• 数据库（带有实体参考）
• 业务（带有数据库和实体引用）
• 用户界面（带有业务和实体参考）

  ---

这是我的代码示例：

• 数据库层中的 UserDAL 类：

等等...

在业务层的 UserBLL 类中，我这样写：

在 UI 中我写道：

好吧，我使用一个名为 ProjectException 的类来产生一个错误，其中包含我创建的 BLL 消息和操作系统自动操作的异常消息。我还创建了一个可能错误的枚举，这里的字典是关于它的一些细节：

这个好吗？它对我有用。你有什么想法？

作为我上一个问题的延续，（请参阅https://stackoverflow.com/questions/3737848/creating-a-loosely-coupled-scalable-software-architecture

有人建议也像我从三层项目的表示层抽象 BLL 一样抽象 DAL。关于如何做到这一点的任何建议？我还需要在 BLL 和 DAL 之间建立一个工厂吗？我需要你们的意见。谢谢。

鉴于：

• 你有一个包含表示层、业务层和数据层的架构。
• 您正在应用领域驱动设计。
• 您正在使用一个对象关系映射器，它可以让您创建面向对象的查询（例如，NHibernate，它可以让您创建 HQL 查询）。

问题：

您应该将面向对象的查询放在哪一层？

我的想法：

我认为将它们放入表示层通常是没有意义的。但我不知道是否将它们放入业务层或数据层。

示例（NHibernate）：

假设您的业务逻辑需要一些方法 GetCustomersPossiblyInterestedIn(Product p)。然后，您可以创建一个复杂的 HQL 查询，该查询选择客户已经购买了与 p 属于同一类别的产品的客户对象。

论点 a)

一方面，我会说这个查询显然是业务逻辑，因为根据客户是否购买了同一类别的产品而将其视为可能对产品感兴趣的决定是一个业务决策。您不妨选择在同一类别中以相似价格购买过多个产品的客户，例如

论点 b)

另一方面，业务层不应该依赖于数据层，所以直接在业务层使用NHibernate敲响了警钟。

可能的解决方案 1)

创建您自己在业务层中使用的面向对象的查询语言，并在数据层中转换为 HQL。我认为这会导致很多开销。如果您使用基于查询对象的查询语言而不是解析的查询语言，您可能会付出一些努力，但我的反对意见仍然适用。

可能的解决方案2）

在业务层直接使用NHibernate 是可以的，因为NHibernate 能够提供HQL、ISession 等的抽象级别适合业务层。没有必要包装它。

你怎么看？

编辑：

有关密切相关的讨论，请参阅Ayende Rahien 的“Repository is the new Singleton”和“在 DAL 中封装数据访问的错误神话” 。

伙计们，

我有一个 ASP.NET 项目，按名称空间划分为 n 层，但我需要分成三个项目：数据层、中间层和前端。

我这样做是因为...

A) 这似乎是正确的做法，并且

B) 我在为 ASP.NET 托管程序集运行单元测试时遇到各种问题。

无论如何，我的问题是，您将配置信息保存在哪里？

例如，现在，我的中间层类（使用 Linq to SQL）在实例化新数据上下文时会自动从 web.config 中提取它们的连接字符串信息。

如果我的数据层在另一个项目中，它可以/应该使用 web.config 获取配置信息吗？

如果是这样，单元测试（通常在单独的程序集中）将如何提供 soch 配置信息？

感谢您的时间！

场景：我有一个包含表示层（ASP.NET）、业务逻辑层（dll）和数据层（dll）的场景，后者有一个 LinqTOSQL DataContext 文件（dbml），其中包含特定数据库的表和存储过程. 项目之间的联系是：

依赖关系：业务逻辑层有数据层的参考表示层有业务逻辑层的参考

我的问题：问题是当我需要返回与数据上下文对应的表类型的对象时，我遇到了一些情况，但是由于表示层没有对数据层的引用，所以我不能使用表对象。 .直接在表示层中引用数据层是一种好习惯吗？或者有人可以指导我如何从表示层实现表格的最佳方式