问题标签 [bll]

我正在编写一个客户端/服务器系统。服务器采用 DAL/BLL 设计。客户端负责呈现数据对象并提供对话框和向导以允许用户更新这些对象（即添加/编辑用户）。

最初我以为我会让 DAL 对象有一个通用的数据提供者对象，以便客户端和服务器都可以使用它们。例如，当服务器使用数据对象时，数据库是数据提供者；当客户端使用数据对象时，服务器是数据提供者。

所以一个对象在表现层被改变了，比如一个“user”：user->setName(“Fred”)，然后像这个user->commit()一样提交它，commit方法调用数据提供者的commit方法，然后对对象进行编码并将其发送到服务器。然后服务器用业务层对象“装饰”它并从那里继续。

我目前将此作为原型工作，在客户端和服务器都使用的共享项目中定义了 DAL 对象。然后服务器注入它的数据提供者（它使用数据库），客户端注入一个使用服务器的数据提供者。

我想知道这是否是一种合理的方法？我一直想知道我是否需要另一层而不是将 DAL 对象直接暴露给客户端。也许是一个数据传输对象层，它会给我 3 层：数据访问对象、业务逻辑对象和数据传输对象。

谢谢。

我目前正在研究 RIA 服务，以加快 Silverlight 企业应用程序的开发。它既聪明又强大，但在我看来，您总是要将业务逻辑折叠到表示层中。使用 RIA 时是否有经典 BLL（业务逻辑层）的位置？

更新：做了更多的研究。看起来当前公认的最佳实践是使用 MVVM 实现 RIA，VM 作为客户端类运行，并包含您的业务逻辑。

我正在设计一个 C# 应用程序

• 演示文稿（网站 + 弹性应用程序）
• 业务逻辑层（可能是 WCF 以启用多客户端平台）
• 数据访问层（使用 NHibernate）

我们将把我们的解决方案集成到许多预先存在的客户数据库环境中，我们想在 DAL 中使用 NHibernate。我的同事指出，使用 NHibernate 从客户的数据库（如用户或图像）生成类会导致 BLL 崩溃每次数据库更改时都在我们面前！所以问题是我们如何防止这种情况发生？我们正在考虑使用 AutoMapper 创建业务对象并将 NHibernate 对象映射到这些 BO（嗯，这会使它们成为 DTO 吗？）并防止 dal 更改影响 BLL .. 这是要走的路吗？

谢谢 ！

编辑 ：

为了更好地理解我们想要实现的目标，您可能需要上下文：我们正在为前端和 C# 构建一个照片存储/共享应用程序，主要用于我们公司，所以我们处理代码和数据库的各个方面。

但是：该产品也可以按层购买，最终已经有一个带有用户表或图像表的数据库。我在这里考虑一个新的潜在客户，他有一个包含几亿行的 Image 表，并且由于表的 ALTERing 太长而不会为我们的业务逻辑添加列。

尽管这是可能的（例如，用户表可以因为较少的行而被修改），但我们在问自己如何处理表结构更改而不影响我们的所有解决方案，每次我们必须从 BLL 集成到层数据库中到 Flex 中的客户端应用程序！

解决方案设置：

• DAL（类库）
• BLL（类库）
• 通用（类库（一些通用功能 - 枚举、日志记录、异常...））
• 应用程序 1（Windows 应用程序）
• 应用程序2（Windows 应用程序）
• WebApp（网络应用程序）
• ...

假设我有一个客户实体，即：

• SQL server 中的一个表
• DAL 中的 CustomerDataTable
• BLL 中的客户类
• 所有应用程序中的 BLL.Customer 类

BLL 和 DAL 应该使用什么样的对象进行通信 -DataTable或List<Customer>（例如）？在第一种情况下，BLL 逻辑应该将 Customer 对象转换为 DataTable 并将其发送到 DAL。在第二种情况下，DAL 层应该知道位于 BLL 层中的 Customer 类。但是最初的 DLL 引用了 DAL 而不是相反...

我是否应该将所有类放入单独的程序集中，由所有其他程序（Common、BusinessObjects、...）引用？在这种情况下，我可以在所有项目中使用 Customer 类。

当我知道只有一个 BLL 会使用我的 DAL 时，我是否应该费心将 DAL 和 BLL 分开。在这种情况下，我可以将它们合并到一个项目中。

PS - 我正在阅读有关 DataTables 的信息，很多人说我们根本不应该使用它们。有什么更好的选择？也许是时候让我学习一些 ORM 映射工具了 :)

我正在开发一个需要业务层和数据访问层的新业务应用程序。

现在，我将这两个作为简单的 C# 类库，将由 Silverlight RIA 应用程序和 WCF 应用程序（将作为 SOAP Web 服务公开）使用。

将这些层开发为 C# 类库而不是使用 WCF 库有什么缺点吗？

所以，而不是 Silverlight->RIA (ASP.Net)->BLL C# 类库->DAL C# 类库->EF->SQL Server

去 Silverlight->RIA (ASP.Net)-> | 会更好吗？（网络）| ->BLL WFC 库->DAL C# 类库->EF->SQL Server ？

我正在为我的应用程序构建一个 BLL。从我所见/所读，似乎 BLL 应该是无状态的。这是否意味着所有 BLL 方法都可以是静态的？或者我至少只需要每个 BLL 类的一个实例？出于某种原因，这对我来说似乎很奇怪，所以我想我最好在深入研究我的实验之前检查我没有得到错误的结果。

我还认为这意味着 BLL 对象不应该包含数据，因为数据代表状态 - 因此对于调用的每个 BLL 操作，需要重新查询（或从缓存中获取）所需的任何数据，然后丢弃。那个听起来是对的吗？

谢谢。

我最近一直在学习数据访问层、业务逻辑层和表示层，但是我还有一些不太清楚的东西。

我可以将 DAL 和 BLL 与表示层一起使用来获取或设置数据库中的信息。

但我也想过asp控制事件，以及我应该如何实现它们。

例如，我应该尝试将按钮单击事件放入 BLL 中，还是应该将其留在 aspx 代码隐藏文件中？

如果我应该将它们放入 BLL，我将如何做呢？

我不确定如何让事件调用 BLL 中的方法，因此将不胜感激任何建议。

在过去的几天里，我使用 DAL/BLL/UI 方法进行了大量研究，但并没有非常清楚地了解它将如何应用于我的项目。过去，我省略了将我的 UI 直接连接到数据访问层 (LINQtoSQL dbml) 的 BLL。但是，我认为这不是我现在（甚至可能是过去）工作的好主意，因为我们有很多不同的应用程序，我想使用与构建相同的 DAL/BLL。

我的问题是，在我的大多数应用程序中，当我真正做的只是使用 LinqtoSqlDataSource/GridView 连接到我的数据上下文以处理所有更新/编辑等时，BLL 如何帮助我。此外，每个新网站在某种程度上，应用程序需要对 DAL/BLL 进行唯一更改才能获取所需数据，这可能会影响使用相同 DAL/BLL 的其他应用程序。重用 DAL/BLL 是正确的方法还是我错过了什么？

我认为当我需要构建例如将要构建的各种 Web 应用程序的安全类时，BLL 就会出现。但是，当我使用 Linqtosql 数据源时，为什么还要费心将它连接到 BLL？

达尔

• LinqToSQL dbml 数据上下文。
• 使用 LinqToSQL 会改变我应该如何使用这种设计吗？

BLL

• 公司使用的各种网站的安全性。
• 查询 DAL 在使用 LinqToSQLDatSource 时返回什么（？），处理各种结果集的函数（我真的不确定这应该如何与 BLL 一起使用，如果问题不清楚，请抱歉）

用户界面

• 仅参考 BLL？

我正在尝试创建一个与我的数据库数据绑定的转发器控件。这应该与 BLL 一起使用。但我不知道我必须做什么。

我希望有人可以帮助我解决这个问题..

我在 page.aspx.vb 中使用的代码是：

我在 page.aspx 中使用的代码是：

我正在构建我的 Web 应用程序以连接数据库。到目前为止，我已经设法处理它，（虽然我没有建立 BLL 和 DAL）。

我有一个包含“id”列的表。我知道有一种方法可以在 SQL Server 中声明它以自动递增。（但我不想要它）。

我想声明一个将保存该值的全局应用程序变量。

我有两个问题：

1. 我如何声明它？

2. 我在哪里创建并初始化它？（我有几个登录页面）。

谢谢！

ps

如果有人能告诉我如何用我的存储过程构建 DAL，那会很有帮助？对于我需要你使用我在 DAL 中不能做的 BLL 吗？