问题标签 [3-tier]

多年来，3 层设计一直是我对数据库驱动应用程序的标准设计理念，它从未让我失望过。对于那些练习它的人，描述你的层次。

我发现很多人混淆了业务层和数据访问层，使其更像是 2.5 层设计。

我更喜欢使用存储过程将数据层几乎完全移动到数据库中，并且只在代码中拥有一个非常轻量级的数据层，将 sproc 调用包装到业务对象中。

你如何处理它？

编辑：如果您要做的只是定义 3 层是什么，请不要浪费时间回复。我正在寻找具体的人如何实现它，您使用存储过程还是 ORM，您如何处理 DAL 和 BLL 之间的循环依赖关系？除了说之外，这个话题还有很多深度

• 用户界面
• 商业
• 数据

我正在尝试将 ASP.net DropDownList 绑定到实体框架查询的结果，同时仍保持多层分离。（即，我不希望我的 UI 代码包含查询详细信息，也不希望我的数据层代码具有 UI 依赖项。）我在 Page_Load 事件处理程序中的代码隐藏如下所示：

虽然我的数据代码看起来像这样（还有一个中间业务层，但那里还没有处理——只是一个传递。）：

当我到达 DocTypeDropDownList.DataBind(); 时，它会抛出一个带有消息“DocTypeDropDownList.DataBind();”的 ObjectDisposedException。谁能告诉我解决这个问题的最佳方法？

谢谢，安迪

我能够验证登录页面的简单方法。如何在 3 层架构中进行身份验证？请有人向我发送 DAL、BAL 和 GUI 层中应该包含什么的代码？这是我的简单代码：

网络配置：

登录.aspx.cs：

几年来，我一直在使用三层架构（表示层、逻辑层和数据层）来编写应用程序。通常，我使用 .netTiers 等工具来生成数据层和部分逻辑层。一切都定义明确，我喜欢它。

我现在受限于使用 LINQ to Entites（似乎 LINQ to SQL 已被微软放弃），我真的很困惑。在我看来，LINQ to Entites 生成的代码是我几乎无法控制的逻辑和数据层的混合体。此外，我真的不喜欢我必须使用生成的类（实体...）这一事实。

最后，您能否分享一下您使用 LINQ to Entities 的经验和最佳实践？知道我如何仍然拥有定义明确的三层架构吗？

谢谢！

Here is my situation: I am trying to follow as hard as I can the 3-tier pattern (i.e. Presentation, Business and Data layer). When I need data from the DB, the Business layer calls the Data layer which returns the information. The Data layer never return a SqlDataReader or DataTable object, but often an enumeration of custom object known by the Data Access Layer. It works pretty well when the Data layer has to return a list with few objects.

I am now facing this problem, my application (the business layer) must process 500000 records. I could simply add another method to my Data layer and return an IEnumerable but this sound very bad to me. I don't want to load half-million records in memory.

My question is, considering the 3-tier model, how should I handle this case? If I had no 3-tiers pattern, I would simply use SqlDataReader in my business classes. Any suggestions?

UPDATE: The data will not be displayed, so this is not a paging issue (the presentation layer is not involved at all here). I simply have to analyze each record and then keep some of them.

Thanks

目前我正在设计我的学位项目。几天前我开始学习LINQ。我发现它很有趣，并计划在我的项目中使用它，但现在我在某些时候感到困惑。

当我添加 LINQ to SQL 类时，它会针对数据库中的每个表自动生成实体类。

假设我在数据库中有两个表：

用户
项目
UserProjects（联合表）

以及一个表示哪个用户与哪个项目相关联的联合表。

LINQ to SQL 类自动为我生成这三个类。现在我应该创建单独的（用户和项目）类作为业务对象还是使用这些自动生成的实体？

此外，要使用数据库功能，我们需要使用 3 层架构。我可以直接从我的 BLL 调用 LINQ DAL 方法还是需要创建单独的 DAL 来调用 LINQ DAL 的方法？

上面的方法调用顺序好吗？

在 BLL 中返回业务规则错误的最佳实践是什么？我应该只引发异常并在表示层中捕获它们，我应该返回某种包含任何异常类型信息的对象吗？

我正在开发一个 ASP.NET 2.0 网站。我已经创建了数据访问和业务逻辑层。现在在表示层中，我从业务层返回数据作为数据集。

我的问题是是否使用数据集或对象集合（例如，表示我数据库中 Category 表的 Category 对象）。我已经定义了映射到数据库表（公共对象）的所有类。但是在某些情况下，我需要表示层中类别表中的所有记录。我只是困惑。我该怎么办？

我有一个 3 层的 .NET 2.0 应用程序。表示层引用中间层。中间层引用数据库层。出于某种原因，当我编译时，数据层的 dll 出现在表示层的 bin 中。我该如何阻止这个？

我一直在阅读 Pro ASP NET MVC Framework 这本书，我对很多事情感到非常困惑。我一直在尝试做一些研究，但我发现有这么多不同的方法和概念被扔给我，这只会让事情变得更糟。
所以我有几个问题：

1. 我知道 MVC 应该将功能分为三个主要部分：模型 -> 控制器 -> 视图。MVC 是不是与三层架构不同的方法？还是我仍然应该考虑在我的项目中创建数据访问层和业务逻辑层？

2. 存储库到底是什么？它是什么充当我的数据访问层？存储库在哪里/如何适合 MVC？

3. 这本书讨论了使用 LINQ to SQL 与数据库进行交互，但它指出未来将不支持 LINQ to SQL，并且微软正在将其用于实体框架。实体框架在哪里适合 MVC，我如何与之交互？

在此先感谢您的帮助！
马特