问题标签 [n-tier-architecture]

这是一个非常非常基础的问题。

假设我想在今天构建一个具有 n 层架构的 .NET 企业 CRUD 应用程序。我应该使用什么数据访问方法？我想要互操作性，所以 DataSets 出来了（我想它也不再是 2003 年了）。同样，.NET RIA Services 所宣传的通过附加服务向非 Silverlight 客户端公开其功能的方法对于更新操作来说似乎不是很有说服力。我已经能够用 Entity Framework 拼凑一些东西，它没有 n 层支持 OOB，因此需要许多奇怪的反射类型的东西来模拟乐观并发的外表（MSDN Magazine 中的示例没有看起来它不支持乐观并发。我听说这在 EF4 中得到了改进，但我有点怀疑，除了在 CTP 中它还没有真正可用）。

那么，人们实际上可以在他们的企业 CRUD 项目中使用更新检查的乐观并发做些什么呢？数据集？使用 DTO 进行 DIY，天知道涉及多少工作？以及如何处理绑定数据？假设我有一个绑定到 DataGrid 的集合，我是否需要听 CollectionChanged 进行更改？我是否需要保留大量更改，以便在撤消时比较 PK？这似乎是噩梦。

其次，如果更新检查乐观并发不是硬性要求怎么办？然后怎样呢？

我正在使用基本的 3 层设计。出于灵活性（和测试）的目的，我希望数据层是抽象的，并在我的代码中指定具体的类。但是，我应该如何将它传递给我的业务对象。这是一个示例（伪代码）：

那么问题来了，PersonBAL 怎么知道要使用哪个 ConcreteDataLayer 呢？我在几个选项之间考虑：

1：将具体的数据层传递给person。当您开始添加需要与数据层交互的新类时，这会变得很痛苦（比如 new PersonBAL(IDataLayer, int)，然后是 new JobBAL(IDataLayer, int) 等）

2：创建一个包含要使用的数据层的静态对象（读取：全局变量）

还有其他想法吗？

我想知道为负载平衡的 n 层系统设计数据库连接管理器的最佳方法。

经典的 n 层如下所示：

我看到的负载平衡解决方案将如下所示：

如图所示，业务服务器组件通过多个实例进行负载平衡，硬件网关在它们之间分配负载。

会话服务器可能需要位于负载平衡阵列之外，因为它管理状态，不能重复。

到目前为止，除非设计中出现任何重大错误，否则实现数据库连接管理的最佳方式是什么？

我想出了几个选项，但可能还有其他我不知道的选项：

1. 在 DBServer 和其他组件之间引入一个新的 Broker 组件，让它处理 DB 连接。

   • 好处是可以从单点管理所有连接，非常方便。
   • 缺点是现在系统中多了一个“单点故障”。对于以某种方式涉及 DB 的每个请求，其他组件都必须经过它，这也成为了瓶颈。
     
     

2. 将 DB 连接管理移到 BusinessServer 和 SessionServer 组件中，让每个组件处理自己的 DB 连接。

   • 好处是没有额外的“单点故障”或瓶颈组件。
   • 缺点是除了 DBServer 本身可以提供的之外，也无法控制可能的冲突和死锁。

还有什么可以做的？

FWIW：技术是 .NET，但没有使用任何供应商特定的堆栈（例如，没有 WCF、MSMQ 等）。

在这个答案中，他说我可以在创建我的 3 层解决方案时使用 RIA 服务，它如何帮助我以及如何节省我的时间，因为当我在 msdn 上检查它时，我发现 RIA 与银光有关，而我正在创建一个普通的 asp.net 网站。

假设我有一个 ASP.Net MVC 应用程序，这个应用程序 (UI) 引用了一个业务逻辑层 (BLL)，而 BLL 引用了我的数据访问层 (DAL)。

我正在使用自定义成员资格和角色提供程序进行授权。

我正在尝试确定哪些层需要引用我的会员资格提供者。

在 MVC 中，您可以通过以下方式执行授权检查：

在我的 BLL 中，我可能想检查用户是否也处于角色中：

如果我这样做，我将不得不在两个层中引用和实例化 Membership 类。这是构建这样的应用程序的正确方法吗？似乎有很多冗余。

由于我有 BLL，我是否应避免使用“[Authorize(Roles = "SomeRoleName")]”属性，而是从 MVC 代码中调用 BLL 函数来检查用户是否处于角色中？如果我这样做，MVC 仍然需要对成员资格提供程序的引用以进行身份​​验证，并且无论如何都要利用登录和其他 ASP 控件，对吗？

我是否偏离了基地并朝着错误的方向前进？

我有一个现有的 .Net 单层 Web 应用程序，它是使用 EntityDatasource 对象在标记中使用声明性数据绑定构建的。我正在从 UI 中提取层（业务逻辑、数据访问）并将其迁移到 ntier 应用程序。

此应用程序使用声明式数据绑定。例如：

是在 ntier 环境中使用声明性数据绑定，还是必须手动将数据绑定到业务对象？

如果您可以在应用程序类型中使用声明性数据绑定，是否有人有一些示例可以指出我可以学习如何实现的地方？

我想我可以从 BLL 执行 LINQ 查询来填充 EntityDataSource 但不确定这是否可行。

EntityDataSouce 对象是否在 n 层 UI 中占有一席之地？

如果想学习如何在 .net 中编写 n-Tiered/分布式应用程序，我应该从 COM+/Remoting/Web Services/WCF 开始学习什么技术？

这些技术是互补的还是排他的，在什么程度上？

我目前正在使用 .NET 3.5 框架开发一个 n 层（3 层）ASP.NET Web 应用程序。

我想知道如何利用 n 层应用程序的“最佳实践”以最快的方式将数据加载到列表控件和下拉列表中。

使用最新且可行的技术（ASP.NET MVC、实体框架、用于 UI 的 Telerik Combobox、AJAX 等）的最佳实践是什么？

我的团队正在设计一个域模型，它将在统一的存储库抽象背后隐藏各种不同的数据源。这种方法的主要驱动因素之一是这些数据源在不久的将来发生重大变化的可能性非常高，我们不希望在发生这种情况时重写业务逻辑。一个数据源是我们的会员数据库，它最初是使用默认的 ASP.Net Membership Provider 实现的。成员资格提供者与 System.Web.Security 命名空间相关联，但我们有一个设计指南，要求我们的域模型层不依赖于 System.Web（或任何其他实现/环境依赖项），因为它将在不同的环境中使用 -我们也不希望我们的网站直接与数据库通信。

我正在考虑将 MembershipProvider 方法与我们抽象的 n 层架构相协调的好方法。我最初的感觉是我们可以创建一个与域模型交互的“DomainMembershipProvider”，然后在模型中实现处理存储库和处理验证/业务逻辑的对象。然后，存储库将使用我们的（尚未确定的）ORM/数据访问工具来实现数据访问。

这种方法是否有任何明显的漏洞——我没有与 MembershipProvider 类密切合作，所以很可能会遗漏一些东西。或者，您认为有没有一种方法可以更好地满足我上面描述的要求？

提前感谢您的想法和建议。

问候，扎克

作为一名软件工程师，我强烈倾向于在应用层编写业务逻辑，而通常只依赖数据库进行 CRUD（创建检索更新和删除）操作。另一方面，我遇到过大量业务逻辑写在存储过程中的应用程序（通常是较旧的应用程序），因此有些人更喜欢在数据库层中编写业务逻辑。

对于拥有和/或喜欢在存储过程中编写/编写业务逻辑的人，您使用此方法的原因是什么？