我更新了这个答案，因为Developr的评论似乎表明他希望有更多的细节。
简短回答你的问题是是的，你需要使用类实例（对象）来调解UI和业务逻辑层之间的接口。BLL和DAL将如下所述进行通信。您不应该在它们之间传递SqlDataTables或SqlDataReaders。
简单的原因是：对象是类型安全的，提供Intellisense支持，允许您在业务层中进行添加或修改，而这些在数据库中并不一定存在，并且让您有一些自由来断开应用程序与数据库之间的联系，以便您可以在数据库变化时保持一致的BLL接口（当然，在某种程度上）。这只是好的编程实践。
大局是，对于您UI中的任何页面，您都将拥有一个或多个要显示和交互的“模型”。对象是捕获模型当前状态的方法。在过程方面：UI将从业务逻辑层（BLL）请求模型（可能是单个对象或对象列表）。然后，BLL使用数据访问层（DAL）的工具创建并返回此模型。如果在UI中对模型进行更改，则UI将向BLL发送修订后的对象，并附带指示如何处理它们的说明（例如，插入、更新、删除）。
.NET非常适合这种关注点分离，因为通用容器类 - 特别是List<>类 - 对于这种工作非常完美。它们不仅允许您传递数据，而且还可以通过ObjectDataSource类轻松集成复杂的UI控件，例如网格、列表等。您可以使用ObjectDataSource实现需要开发UI的全套操作：“填充”具有参数的操作、CRUD操作、排序等。
由于这相当重要，让我快速转移一下，演示如何定义ObjectDataSource：
<asp:ObjectDataSource ID="ObjectDataSource1" runat="server"
OldValuesParameterFormatString="original_{0}"
SelectMethod="GetArticles"
OnObjectCreating="OnObjectCreating"
TypeName="MotivationBusinessModel.ContentPagesLogic">
<SelectParameters>
<asp:SessionParameter DefaultValue="News" Name="category"
SessionField="CurPageCategory" Type="String" />
</SelectParameters>
</asp:ObjectDataSource>
这里，
MotivationBusinessModel是BLL的命名空间，而
ContentPagesLogic是实现内容页面逻辑的类。提取数据的方法是"
GetArticles"，它需要一个名为
CurPageCategory的参数。在这种情况下，ObjectDataSource返回一个对象列表，然后由网格使用。请注意，我需要将会话状态信息传递给BLL类，因此在代码后台中，我有一个方法"
OnObjectCreating"，让我创建对象并传递参数。
public void OnObjectCreating(object sender, ObjectDataSourceEventArgs e)
{
e.ObjectInstance = new ContentPagesLogic(sessionObj);
}
所以，它是如何工作的。但有一个非常重要的问题 - 模型/业务对象从哪里来？ORM（对象关系映射）如Linq to SQL和Subsonic提供代码生成器，让您为每个数据库表创建一个类。也就是说，这些工具认为模型类应该在您的数据访问层（DAL）中定义，并直接映射到数据库表。Linq to Entities允许您以与数据库布局完全不同的方式定义对象，但相应地更加复杂（这就是为什么Linq to SQL和Linq to Entities之间有区别）。实质上，它是BLL解决方案。Joel和我在本文的各个地方都说过，实际上，业务层通常是应该定义模型的地方（尽管我现实中使用了一种BLL和DAL对象的混合方法）。
一旦决定这样做，如何实现从模型到数据库的映射呢？好吧，您编写BLL中的类来拉取数据（使用您的DAL），并填充对象或对象列表。这是“业务逻辑”，因为映射通常伴随着附加逻辑来充实模型（例如，定义派生字段的值）。
Joel创建静态Factory类来实现模型到数据库的映射。这是一个很好的方法，因为它使用了一个众所周知的模式，并将映射放在要返回的对象的构造中。您总是知道要去哪里查看映射，整体方法简单明了。
我采取了不同的方法。在我的BLL中，我定义了“逻辑”类和“模型”类。这些通常以匹配对的形式定义，其中两个类在同一文件中定义，它们的名称通过其后缀区别（例如ClassModel和ClassLogic）。逻辑类知道如何使用模型类 - 执行如填充、保存（“Upsert”）、删除和为模型实例生成反馈等操作。
特别是，为了进行填充，我利用了在我的主DAL类中找到的方法（如下所示），让我可以获取任何类和任何SQL查询，并找到一种方法来使用查询返回的数据创建/填充类的实例（无论是单个实例还是列表）。也就是说，逻辑类只需获取模型类定义，定义SQL查询并将它们发送到DAL。结果是可以传递给UI的单个对象或对象列表。请注意，查询可能会返回来自一个表或多个连接在一起的多个表的字段。在映射级别，我真的不关心 - 我只想填充一些对象。
这是第一个函数。它将自动将任意类映射到从查询中提取的所有匹配字段。匹配是通过找到与类中属性匹配的字段来执行的。如果有额外的类字段（例如，您将使用业务逻辑填充的字段）或额外的查询字段，则会忽略它们。
public List<T> ReturnList<T>() where T : new()
{
try
{
List<T> fdList = new List<T>();
myCommand.CommandText = QueryString;
SqlDataReader nwReader = myCommand.ExecuteReader();
Type objectType = typeof (T);
PropertyInfo[] typeFields = objectType.GetProperties();
if (nwReader != null)
{
while (nwReader.Read())
{
T obj = new T();
for (int i = 0; i < nwReader.FieldCount; i++)
{
foreach (PropertyInfo info in typeFields)
{
if (info.Name == nwReader.GetName(i))
{
if (!nwReader[i].Equals(DBNull.Value))
info.SetValue(obj, nwReader[i], null);
break;
}
}
}
fdList.Add(obj);
}
nwReader.Close();
}
return fdList;
}
catch
{
conn.Close();
throw;
}
}
这是在我的数据访问层（DAL）中使用的，但你只需要在DAL类中拥有一个QueryString的变量、一个带有打开连接和任意参数的SqlCommand对象即可。关键是确保当调用时ExecuteReader函数能够正常工作。因此，我的业务逻辑层（BLL）通常会这样使用该函数：
return qry.Command("Select AttendDate, Count(*) as ClassAttendCount From ClassAttend")
.Where("ClassID", classID)
.ReturnList<AttendListDateModel>();
你也可以这样实现对匿名类的支持：
public List<T> ReturnList<T>(T sample)
{
try
{
List<T> fdList = new List<T>();
myCommand.CommandText = QueryString;
SqlDataReader nwReader = myCommand.ExecuteReader();
var properties = TypeDescriptor.GetProperties(sample);
if (nwReader != null)
{
while (nwReader.Read())
{
int objIdx = 0;
object[] objArray = new object[properties.Count];
for (int i = 0; i < nwReader.FieldCount; i++)
{
foreach (PropertyDescriptor info in properties)
{
if (info.Name == nwReader.GetName(i))
{
objArray[objIdx++] = nwReader[info.Name];
break;
}
}
}
fdList.Add((T)Activator.CreateInstance(sample.GetType(), objArray));
}
nwReader.Close();
}
return fdList;
}
catch
{
conn.Close();
throw;
}
}
调用它的方式如下：
var qList = qry.Command("Select QueryDesc, UID, StaffID From Query")
.Where("SiteID", sessionObj.siteID)
.ReturnList(new { QueryDesc = "", UID = 0, StaffID=0 });
现在，qList是一个动态创建的类实例通用列表。假设你的业务逻辑层（BLL）中有一个函数，它以下拉列表作为参数，并请求使用数据填充该列表。以下是如何使用上述检索结果填充下拉列表的方法：
foreach (var queryObj in qList)
{
pullDownList.Add(new ListItem(queryObj.QueryDesc, queryObj.UID.ToString()));
}
简而言之，我们可以动态定义匿名的业务模型类，并通过向数据访问层传递一些（动态生成的）SQL来填充它们。因此，响应UI不断变化的需求时，BLL非常容易更新。
最后注意一点：如果你担心定义和传递对象会浪费内存，你不必担心：如果你使用SqlDataReader来提取数据并将其放入列表中组成的对象中，你只会有一个内存副本（即列表），因为读取器以只读、单向的方式迭代。当然，如果你在数据访问层中使用DataAdapter和Table类等，则会产生不必要的开销（这就是为什么你不应该这样做）。
