编辑 1

我很抱歉，但在阅读了 2 篇建议的文章后，我仍然不明白我应该使用什么。我知道由于各种原因不首选使用 IQueryable ，但这是否也消除了 IEnumerable ？DataTable 真的是我最好的选择吗？

简而言之，我猜，首选的返回类型是什么？

我有以下简单的 LINQ 查询，我想将其抽象为 DAL。var 的类型是什么，因此我的方法应该是什么类型？

当我在 VS 中将鼠标悬停在它上面时，它会说IQueryable<T>，但是当我放入断点并运行它时，它似乎称自己为 IEnumerable。哪个是正确的，我应该如何声明我的方法？

像这样 -->

如果我使用IQueryable<T>什么是<T>或者我怎么知道，我会返回什么？

谢谢！

供参考 CopyToDataTable() 如下。

我们目前正在讨论数据集应该放在数据层还是业务层？

我的朋友认为所有 ADO.NET 组件都应该放在数据层中。对我来说，这似乎不正确，原因如下：

• 如果您创建一个胖数据层客户端，例如将所有内容迁移到不同的数据源将会更加困难。
• 除非您跳过业务层逻辑，否则您无法绑定控件。

我认为数据集和数据表应该在业务逻辑中，因为它们对所有数据提供者都是通用的。数据层应该有一个提供者工厂来实例化正确的提供者的对象（连接、数据适配器、事务、数据读取器等）。对我来说，这是要走的路，原因如下：

• 迁移到不同的数据层非常简单。
• 您可以将控件绑定到丰富的业务对象

有没有n级的大师能帮我们弄清楚该走哪条路？

我使用带有实体框架的分层架构作为我的数据层，顶部有一堆存储库，其中包含 Linq-To-Entities 查询。数据层是一个项目，接下来我有一个服务层和界面，它是一个网站。

我希望我的网站负责为我的实体模型指定连接字符串。我该怎么做呢？

我正在使用单例方法访问位于数据层内的实体存储库。

谢谢

由于对设计模式和架构非常陌生，我很难向其他人解释我的最新应用程序是如何设计的。我已经在认为它是纯 n 层、纯 MVC 和表示层中带有 MVC 的 n 层之间切换。目前我认为后者是正确的，但我想要更有经验的开发人员的想法。

这个怎么运作：

1. 浏览器向 Tomcat 发送 HTTP 请求。通过 web.xml 将请求映射到一个 servlet（我称之为控制器）
2. 控制器实例化一个或多个业务对象并在这些对象上调用方法，即customerBO.getById(12)在调用一个或多个 DAO 方法之前再次执行业务逻辑/验证，即customerDAO.getById(12)。BO 将 CustomerVO 列表返回给控制器
3. 控制器为视图（JSP）准备属性request.setAttribute("customers", customers);（

结构（我的建议/理解）

表示层：目前使用我认为是 MVC Web 实现的方式：servlet（控制器）、jsp（视图）和我自己的 OO XHTML 表单实现（即 CustomerForm）就在这里。应该可以通过切换此表示层来使用 Swing/JavaFX/Flex GUI，而无需更改下面层上的任何内容。

逻辑层：分为两层，顶部是业务对象（BO）。负责业务逻辑，但除了输入验证之外，我还没有发现太多可在此处添加的内容，因为应用程序主要由简单的 CRUD 操作组成……在许多情况下，这些方法只是调用 DAO 层上具有相同名称的方法。

带有 CRUD 方法的 DAO 类，它再次与下面的数据层联系。还有一个 convertToVO(ResultSet res) 方法，它们从数据库执行 ORM 并到（列表）值对象。所有方法都将值对象作为输入，即 customerDAO->save(voter) 并在成功时返回更新的投票者，在失败时返回 null。

数据层：底层数据存储在数据库中或作为 XML 文件。除了一些 MySQL 存储过程和触发器，我在这里没有“编码”任何东西。

问题（除了标题中的问题）：

1. MVC 中的 M。我不确定当模型是从逻辑层中的业务对象返回的列表/VO 时是否可以调用此 n 层 MVC？当控制器/视图在这里时，模型是否需要驻留在表示层中？表示层中的表单模板可以称为模型吗？如果是这样的话; BO 中的表单和列表是否都被视为 MVC 中的 M？
2. 据我了解，在 MVC 中，视图应该观察模型并根据变化进行更新，但这在视图是呈现 XHTML 页面的 Web 应用程序中是不可能的？这反过来又让我想到了一个问题：Web 应用程序与常规桌面应用程序的 MVC 实现方式是否不同？
3. 当所有 HTTP 请求都显式映射到 web.xml 时，我没有使用前端控制器模式，对吗？要使用前端控制器，我需要将所有请求转发到标准 servlet/控制器，然后再评估请求并调用另一个控制器？
4. 业务层在我的应用程序中感觉有点“无用”。您通常在此层/对象中放置什么？是否应该始终有一个业务层？我知道它应该包含“业务逻辑”，但这究竟是什么？我只是执行输入验证并实例化一个或多个 DAO 并在它们上调用适当的方法......

我意识到有 MVC 框架，例如 Struts for Java，但是自从这是我的第一个 Java Web 应用程序以来，我试图更深入地了解事物的工作原理。回想起来，我希望你能回答我偶然发现的一些问题。

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

如何将数据传递到 n 层应用程序中的层？我已经制定了 3 种不同的方法。

A) 通用 .net 对象通用数据表、哈希表、通用数据集、字符串、整数等......然后使用数据集填充发送到 UI 层的业务对象。

替代文字 http://img11.imageshack.us/img11/460/generic.png

http://dabbleboard.com/draw?b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133

Pro-不需要额外的层 Con-必须使用业务层中的通用数据集和表

B） 使用其他层将引用的实体层。该层将包含强类型数据集或普通旧 C 对象。这些对象将主要是容器数据和很少的逻辑。这些将是发送到 UI 层的相同对象。

替代文字 http://img8.imageshack.us/img8/6454/entities.png

http://dabbleboard.com/draw?b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa

Pro-在所有层中使用相同的类 将对 entity.dll的引用添加到所有层

C) 使用数据访问层中定义的数据传输对象（仅限容器对象）。然后使用这些对象填充发送到 UI 层的业务对象。

替代文字 http://img43.imageshack.us/img43/1236/transferp.png

http://dabbleboard.com/draw?b=eiu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b

Pro-业务层不必使用通用类 -使用两种类型的对象，您必须将业务对象与传输对象结合起来

我们在工作中进行了讨论，想看看社区的想法。我还添加了一个指向 dabbleboard 的链接。请复制和创建而不是编辑。
谢谢

我正在努力标准化我所有应用程序的分层/n-Tiered 设计的一种单一方式。

我正在尝试将我的所有应用程序分层为 5 层。

代码：

| 用户界面 |

|

| 业务对象 |

|

| 或映射器 |

|

| 数据访问 |

|

| 关系型数据库 |

假设我正在为用户开发一个具有登录/注销功能的应用程序。我在 VS2005 解决方案下创建了 4 个项目。每个项目都针对上 4 层之一。我正在设计我的业务对象类如下：-

这就是我如何为我的对象提供一些与现实世界场景相匹配的功能。这里 GetByUsername() 和 GetByUserTypeCode() 是 getter 函数。这些功能与现实世界的逻辑不匹配。因为，在现实世界中，用户永远不会“通过用户名获取”或“通过 UserTypeCode 获取”。所以这些函数保持静态。

我的 OR Mapper 层类如下：-

最后，DA类如下：-

如果有人仔细研究这些类，他可以理解，OR Mapper 层需要 BusinessObject 层的引用。BusinessObject-layer 也需要 OR Mapper-layer 的引用。

这应该创建一个循环依赖。

我怎样才能避免这个问题？

有人建议使用普通数据传输对象 (DTO)。但是，据我所知，根据 OOP，现实世界对象的属性和功能应该作为一个类组合在一起。如果我使用 DTO，那么如何将功能封装到一个类中？此外，我正在创建另一个没有任何属性（BO）的类。对我来说，这两种方式都违反了 OOP。如果我这样做了，那么 OOP 在这个世界上有什么用？相同的答案可以应用于“UserManager”类。

我找到了一个博客。

它讨论了实现接口。定义一个单独的接口，在 BusinessObject 中的数据类中实现它，并针对 BusinessObject 和 OR-Mapper 层中的接口进行编程。

但我不能这样做。

谁能用一个实际的例子告诉我？

请先阅读以下主题：

C# 和 Visual Studio 2005 中的程序集之间的循环引用

实现接口解决了我的问题，但没有实现我的目标。

我的目标是只使用来自 UI 层/程序集的 BO 层/程序集。这样我就可以保持干净的层到层参考。

因为我不想在 UI 层/程序集中为 BO 层/程序集和 ORMapper-层/程序集添加引用。

我只想在 UI 层/程序集中使用 BO 层/程序集。

同时有人建议我，只能使用反射，而不是 DI。真的吗？

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

我的看法是有，也没有。

1. 它确实将逻辑和数据与 UI 分开，但仍将它们全部塞进一个单点应用程序中。
2. 这就是为什么我认为它不是真的，因为控制器是业务逻辑，视图是 UI，模型是 DAL。这些现在只是同一个应用程序中的层。

但是层应该是第一个或第二个变种，实际上被称为层吗？

有人想加自己的 2 美分吗？