问题标签 [n-tier-architecture]

I am setting up an n-tier application with MVC, Ninject, and NHibernate (my first using these technologies). For clarity's sake, the tiers are a "Data" tier, a "Services" tier, and a "Web" tier (all are separate projects).

With MVC, you have your models that are in the "Models" folder. It seems necessary to put my models here to create strongly-typed Views and to generally keep with the philosophy of MVC.

However, with NHibernate, I also need my models in the "Data" tier so that the mapping can take place and that NHibernate can instantiate actual objects to return to the services layer.

Duplicating the classes across projects is not very DRY and abstracting them into their own library doesn't seem to play well with MVC (neither in practice nor philosophy).

Any thoughts? How do you structure your O/RM objects vs MVC models?

我正在寻找检测本地连接丢失。有没有办法做到这一点，就像 Corelabs 组件上的事件一样？

谢谢

编辑：抱歉，我将尝试更具体一点：我目前正在使用 datasnap 2009 设计原型。所以我有一个瘦客户端、一个无状态服务器应用程序和一个数据库服务器。

我能做的是检测和处理客户端和服务器应用程序之间的连接丢失（互联网连接）以适当地处理它，即：向用户显示一条信息性错误消息或检测服务器关闭以静默重定向另一个应用服务器。

在我使用 ODAC 组件管理的 2 层中，TOraSession 有一些事件来处理这个问题。

在使用自定义实体的 n 层应用程序中，您如何发现自己处理查找表所需的数据？您是否为这些查找表中的每一个创建实体或采用其他策略？

例如。我有一个“评级”查找表，用于填充下拉列表。您会创建一个带有 ratingid 和 rating 属性的 rating 对象并将其传递给您的 UI，还是有更有效的方法来实现它？

欣赏你的想法。

我想知道我应该如何构建我的项目。

我们有一些项目在其他项目中（重新）使用。

我的意思是，我们的数据项目和模型项目用于一对多的其他项目。

我真正知道的是如何构建这种类型的项目，最好的命名方式是什么？

在标准的 3 层应用程序中，应该类似于：

1. DAL、DataAccessLayer、数据...
2. 模型、业务对象、BOL ...
3. 用户界面，视图，...

还有其他想法吗？

在我工作的每家公司，他们都有不同的组织方式，有没有比另一个更好的？您使用哪一种，您更喜欢哪一种，为什么？

谢谢！

我目前正在使用 C# 中的一个小型 N 层应用程序，它使用 Linq-to-Entities（用于 DB 的 SQL Express 2005）和 WPF，我想知道我的业务逻辑层应该向用户界面提供什么类型的数据收集.

将诸如 datagridviews 之类的表单对象绑定到 IQueryable 是否有缺点（性能、验证等）？我应该填充内存中的 DataTable 并将其传递给 UI 吗？DataContext应该在哪一层初始化？

我们有一大套应用程序，大多数是 C# 1.1，但至少有 10 个主要的应用程序是 VB6。我们正在进行一个将 VB6 应用程序升级到 .NET 3.5 的项目。

所有 c# 1.1 应用程序都是使用传统的 n 层方法编写的。UI 层实际上没有任何架构/分离。大多数代码只是响应事件并从那里开始。我想说的是，从可维护性的角度来看，它非常好，并且很容易遵循代码并加快新应用程序的速度。

当我们移植 VB6 应用程序时，最初的想法是我们应该坚持现有的模式（例如 n-Tier）。

我想知道，是否值得打破模式并使用 MVP/MVC 模式做 VB6 应用程序？MVC/MVP winform 应用程序真的更容易维护吗？我在一个基于 MVC 的项目上工作，并没有觉得它更容易维护，但这只是一个项目。

有哪些经验和建议？

我有一个带有表示层、业务层、DAL 和业务对象层的 n 层应用程序。分离对象和写在对象上的操作打破了面向对象的封装概念。

我开发了一个 3 层应用程序，但我遇到了关于从数据库填充数据的问题。我的应用程序有一个从数据库查询大数据的窗口，这个过程需要很长时间。（我的客户端离服务器很远，它之间的连接是 128 KB/s）。

然后我想到了解决这个问题的解决方案。解决方案是每 y 秒填充 x 条数据记录。（例如：首先填充 10 条记录以显示在 UI 上，然后每 5 秒显示更多 10 行）。

这是解决这个问题的好方法吗？有没有更好的方法来解决这个问题？

我开始了我的网站，比如 stackoverflow，我想要偿还一点技术债务。作为一名合同开发人员，我去过很多地方，看到了很多不同的方法来实现这个结果，但我要走的路是……

演示文稿（网络）

业务层（老式实体类和 BL 层）

数据层（通过存储过程到 SQL Server 的 DA 类）

我的问题主要涉及业务层。现在我有一个实体命名空间和一个业务逻辑命名空间。

提单提到了 DA 和实体。实体有对 DA 的引用（DA“不知道”提单或实体）

我真的希望将数据转换为实体的所有工作都发生在 BL 中——也就是业务逻辑中。但是，如果需要，我希望实体能够访问 BL，从而删除实体对 DL 的引用。

所以...

将 BL 和 Entity 对象放在同一个命名空间中以便它们可以一起工作是“错误的”吗？

本质上，我正在尝试拥有一个像 Employee 这样的实体对象（经典示例，嗯？）并让 Employee 有一个

该属性返回向该员工报告的其他员工对象的哈希表。但我不想在需要之前加载它。因此，对于大多数员工来说，该属性永远不会被访问，但当它访问时，它会通过调用 BL 来自动加载，而 BL 会调用 DA。

这个问题有意义吗？

如果是这样，我的解决方案是吗？

提前非常感谢！

我的问题更多的是架构性质，较少涉及实际实现。

我已经构建了一个基于 WCF 的 API，但无法真正决定如何将 PL 与 BL 分开。我已经使我的服务变薄了，因此它只包含最少的实现，例如：

当然，第一个问题出现了，RequestProcessors 属于哪一层？我认为称它们为门面是错误的，但同时，它们与演示无关。至于现在，我决定他们仍然属于 PL。处理器方法将我的 DTO（DataContracts）作为输入，验证请求消息（基类），验证（基类）并最终返回单个 DTO 响应，如下所示：

现在我问自己，为什么我需要 1:1 与我的业务对象相关的外观类。例如，我有一个 HostFacade，它充当 hostDAO 和处理器之间的层。然而，它包含的逻辑很少，它只处理 DAO 调用。

问题：我还不如合并处理器和外观，对吗？

我已经阅读了许多关于该主题的文章/书籍，但我仍然无法确定“正确”的方式，并且每次遇到问题时都倾向于选择不同的方法。我想知道是否存在正确的方法。

我找到了 f.ex。doFactory 示例，他们直接从服务实现中与 DAO 类进行对话。我不太喜欢这样，因为大多数 ServiceContract 方法共享一些逻辑，因此很适合与共享基类一起使用。

我还发现了其他示例，其中仅从服务中调用外观，但这似乎仅适用于非常细粒度的消息。我的消息是“胖”和复合的，以尽可能减少对服务的调用次数。我的额外处理层似乎是我真正的问题。

关于如何正确分层 WCF 服务可能没有单一的答案，但希望你们中的一些人的意见可以符合我的直觉，或者为我在这个主题上提供一些新的见解。

谢谢！

杰弗里