问题标签 [n-tier-architecture]

我正在开发一个将使用 LINQ to SQL 的个人项目（C#/ASP.NET）。该解决方案将（到目前为止）有一个 Webform 项目、一个 Namespace 项目（业务逻辑）和一个 Tests 项目。到目前为止，我处于非常早期的阶段（显然处于设计阶段）。

这里有 3 层架构的范例吗？在这种情况下，DAL 似乎完全没用；感觉我应该直接从业务逻辑执行 LINQ 查询。

我还想到，如果我只保留一个常驻 DataContext 并传递它，我只需要一个打开的连接。这将有一个额外的好处，即一次而不是细粒度地提交更改。对此有什么想法吗？

我找到了这个线程，但它似乎描绘了一幅不完整的画面。有没有关于这个主题的深入文章？

我有一个 3 层 .NET 服务应用程序，它遵循标准方法：

我一直在尝试学习依赖注入，到目前为止发现它很棒（使用 Autofac）。3 层中的每一层都需要创建各种各样的对象，有时还需要额外的配置等。看起来 DI 容器应该是解决这个问题的理想之选，但我遇到了一些问题，看它应该与系统的其余部分相关联。

目前我在前端有一个配置 DI 容器的类。它基本上是一大堆代码container.Register<SomeType>()，等等。

问题是，它正在为所有 3 层配置容器，因此必须对数据访问层有相当深入的了解。在我的前端拥有这样知识的代码会在我脑海中敲响警钟，因为将应用程序分成几层是为了避免这种确切的情况。
更糟糕的是，我的数据访问层不仅仅是 SQL 服务器，它是一个愚蠢的比特桶，而是由许多复杂的 COM 互操作和 P/Invoke 调用组成，因此对 DI 有相当大的影响配置。

我已经考虑过将其分解——也许每层有一个容器，或者在每一层都有一个“设置”类，它与全局 DI 容器对话以注册它自己的位，但我不确定这是否会导致解决的问题多于解决的问题...

如果有人能分享他们在多层应用程序中使用 DI 的经验，我将不胜感激。

谢谢，猎户座。

我有一个项目，我们使用屏幕 DTO 来封装服务层和表示层之间的数据。在我们的例子中，表示层是 ASP.Net。

唯一知道 DTO 的类是服务层类和调用这些服务并显示 DTO 的页面/控件。

DTO 几乎总是特定于页面/控制，所以我觉得它们属于表示层，但这意味着服务层必须引用表示层才能使用 DTO。

我几乎认为服务层应该返回更丰富的对象（但不是域实体？），然后表示层可以获取这些对象并将它们映射到每个页面/控制问题的非常具体的 DTO。

这是一个接口声明和一个 DTO，因此您可以看到我在说什么：

编辑

这是另一个代码示例，用于描述不涉及域模型的用例。也许这会澄清一些事情。我相信我已经超载了 DTO 的含义。我不是在谈论通过网络传输对象的功能的 DTO。我正在创建 DTO 来正式确定与我的服务层的通信之间的合同。

假设我的身份验证突然需要一个 IP 地址参数。我现在可以将该属性添加到 DTO，而无需更改我的合同接口。

我不想将实体传递给我的表示层。我不希望我的代码后面有能力去BlogPost.AddComment(new Comment())

我正在开发一个相对较小的 asp.net Web 应用程序，我想知道是否真的需要采用完整的 n 层架构。对于大小的想法；大约有20个数据库表。

过去，我使用了一种 2 层方法，其中业务逻辑和数据访问被组合到一个类库中，其中一个 asp.net Web 应用程序形成 UI 层，这似乎工作正常。

是否有阈值大小或一些经验法则，您应该在哪里使用 n 层？

例如，如果您有一个名为 Person（ID、Name 等）的数据库表，数据访问层应该将哪种对象返回给业务层？我在想这样的事情：

但这一切似乎有些繁琐？这个问题有更优雅的解决方案吗？我应该将 DataRow 从数据访问层返回到业务层吗？

需要

1. 在 CSLA 部署中从单层迁移到多层时所需的快速配置更改列表
2. 上述清单的详细解释
3. A 如何列出

以前我的 ASP.NET Web 应用程序使用 ADO.NET 直接连接到数据库。现在我想把它改成3层，ASP.NET层，中间Web服务层和后端数据库层。我认为我可以将数据源抽象到 ASP.NET 前端层，松散耦合并减少潜在的安全风险，让外部暴露的 ASP.Net Web 应用程序能够直接访问数据库等的好处。

与 2 层架构和 3 层架构相比，我遇到了 2 个主要问题。

1. 额外的中间 Web 服务层会产生更多的流量，例如 ASP.NET 不直接与数据库对话，而是与 Web 服务对话，而 Web 服务与数据库对话，会产生更多的流量。会不会是瓶颈？如果它是一个瓶颈，任何一般的建议来解决这个问题？

2. 由于 ASP.NET 不能连接到数据库而是连接到 Web 服务，所以它不能轻易获得 DataSet/DataTable 对象。很难将表格数据呈现给数据绑定控件。有什么想法可以让 ASP.NET 中的表示层更容易编码吗？

问候，
乔治

我想大多数开发人员都有多层架构的想法。我们有 DAL（数据访问层），我们有 BLL（业务逻辑层），并且在接近尽头的地方我们有我们的 UI。如果您的项目以某种方式遵循这些原则，您是否保留（或至少尝试）保留/放置它们在概念上属于的地方？我对与许多其他人一起工作的大公司应用程序特别感兴趣。显然，你可以用你的私人玩具项目做任何你想做的事，发明任何类型的架构并坚持下去。对于有很多人为软件做出贡献或整体混乱的大型项目来说，这并不容易。

例如，我碰巧看到诸如 UI 组件直接进入数据库以获取一些 BL 不提供的“丢失”额外数据，UI 和 BL 都使用表字段等低级元素，我认为它们应该委托这些操作到较低级别即 DAL。在与高级开发人员讨论这些事情后，我看到他根本没有看到这有问题，这尤其令人难过。

我们当然可以假设我和任何与我观点相同的人都只是完美主义者，但我清楚地看到了一个非常不利的后果，因为我在一些任务中花了很长时间来追踪所有“平行”路线数据往返于数据库，并确定现在可能受到我实施的新功能影响的人以及以何种方式受到影响。在我看来，当有人决定快速破解这些东西并尽快关闭任务时，这些增加了进一步的开发/维护成本，超过了一些节省。

你的项目是“纯粹的”还是他们很久以前就放弃了在层之间保持清晰界限的想法？如果您仍然保持正确，您将如何处理不了解这些事情或不关心他们只是构建“自定义”解决方案和黑客攻击的同事？或者在某个时间点你停止与风车战斗并接受它作为你的惩罚？

我一直在努力思考如何将我的域对象公开给客户端。无论我使用的是富客户端还是使用 Web，我都想使用 MVP 和存储库模式。

我想要了解的是如何公开我的存储库和模型，它们将在服务器上。是否可以通过 Web 服务公开具有状态的复杂业务对象，或者我是否必须使用与语言/平台无关的专有技术，如 .Net 远程处理、EJB、COM+、DCOM 等？

其他一些限制是我不想每次我想执行操作时都必须不断地从数据库中加载复杂的域对象或通过网络传递它。一些复杂的逻辑可能是屏幕的某些区域可能会根据用户权限以及对象的状态被禁用或不可见。验证和错误消息信息也需要显示给用户。我希望能够在逻辑上调用我的许多域对象操作，就好像它在同一台机器上运行一样。

有了网络，您就可以自由发挥。您不必跨服务边界公开您的对象，因此您可以根据需要使它们变得丰富。我正在尝试创建一个丰富的 N-teir 架构，当调用该模型的客户端在另一台机器上时它可以工作。

我们有一个相对较大的应用程序，它与 Firebird 紧密相关（存储过程、视图等）。我们现在收到很多支持其他数据库的请求，我们还希望将很多功能从客户端转移到服务器。

现在似乎是迁移到 3(4) 层架构的好时机。我们已经看过 DataSnap 2009 和 RemObjects SDK/DataAbstract。两者似乎都可以胜任，但是我们应该注意哪些优点/缺点？您还有其他可以推荐的框架吗？

干杯，保罗