问题标签 [bll]

我有一个这样的类。当网页初始化时，我为每个加载的页面启动这个类，并将这个值作为参数发送给其他类。

例如 ;

学生类使用 ActiveSeason 属性，其他类也使用这些值作为参数。

我的第一个问题，最好的方法是什么。我如何描述这个类，例如常量类或什么。第二个问题，有没有简单的方法可以做到这一点。我的意思是每次查询都传递这些参数会使代码变得混乱，难以阅读。

我有几张我加载的图片。首先我关于第一张图片的问题。为什么这些文件夹似乎带有点。当我查看这些文件夹时，它说它们是“解决方案文件夹”。为什么我们需要这个文件夹，例如我我正在创建一个类库作为一个项目。为什么我应该在“解决方案文件夹”中描述这个项目。

第一张照片。

第二张照片

我关于这个解决方案结构的第二个问题。它由分层架构解决方案指南 2010 创建，从这里下载http://visualstudiogallery.msdn.microsoft.com/c8c473b5-21a1-447a-8b24-33b43411ee7f

它已经有了 bll,dal,bo, 文件夹，为什么我们需要一个共享文件夹。我们应该在其中放置哪些类，我还看到了一个测试文件夹。这个解决方案的主要职责是什么。以及它是如何使用的。谢谢你们。

我的问题与 bll,dal,interfaces 有关。

我的项目结构或多或少是这样的。 BLL、DAL、OBJ 和 3 层架构 （由于我不再重复问题和代码，我在这里给出链接）

我的问题是我为什么要使用接口，有什么好处。以及如何根据上面给出的项目结构应用接口。你能提供链接或答案吗？谢谢大家

我是实体框架的新手（代码优先，如果重要的话）。当我一直在使用它时，我一直在构建我的 POCO 类，将它们视为最终的域模型。对于延迟加载之类的东西，我喜欢这样的想法，即我可以直接在我的表示层中使用这些实体，从而延迟加载我真正需要的东西。

但是，我最近还了解了数据传输对象，这是我以前从未听说过的。这绝对有道理；我的最终域模型的行为可能有一些不属于 DAL 的业务规则。例如，如果SalesOrder我提供给实体框架的 POCO 是否包含它的最终方法，例如，AddItem(Product)如果在. 这听起来绝对像是属于 BLL 的东西。ProductDiscontinuedDateSalesOrder.OrderDate

所以，我想这意味着我给实体框架的 POCO 类应该更像 DTO 的？，就像SalesOrderDto只是EmployeeDto简单的小数据持有者，只有属性，没有方法，然后被映射（可能使用 AutoMapper）到我的 BLL 中的域对象，然后传递给表示层？

我是在正确的轨道上，还是我错过了什么。我感到困惑，因为 DTO 的想法非常有意义，但我从未见过它们在实体框架的上下文中使用。

我听说过很多次将您的 DAL 放入类库中。这是有道理的，我想这样做是为了减少跨应用程序的代码重复。我决定使用实体框架来构建该 DAL。

然而，根据我对 N 层应用程序的理解，DAL 实际上只是公开 POCO 类，我将把它当作 DTO 对待。为了使这更容易，我的 DAL.dll 将公开类EmployeeDto和方法GetEmployeeDtoByID(int ID)，以明确这一层不会产生最终的域模型。

但是如果我想要一个生成最终域模型的可重用 DLL 怎么办？能够创建一个新项目，添加 CompanyBLL.dll 引用，并在GetAllEmployees知道此处公开的类是该对象的域模型的真实表示后开始调用，这当然会很好。从本质上讲，我所做的每个项目都只是一个新的表示层，用于所需的不同工具。

我知道这些是我在开始部署 N 层应用程序时应该做出的个人选择，但这是一个合理的目标吗？如果是这样，我是否制作 DAL.dll，并且仅在构建 BLL 类库时才真正引用它？将它们组合到一个单一的类库中会更有意义吗？

我只是不确定我是否因为不想为我制作的每个应用程序重建我的业务逻辑而疯狂，以及这是否是正确的方法。

我正在使用 n 层方法将大型 Classic ASP Web 应用程序转换为 ASP.Net MVC。在我的 DAL 中，我使用 ADO.Net 来查询数据库并将查询转换为对象。我还有一个用于计算和验证之类的 BLL。

我的问题涉及在需要计算以将查询转换为对象时在 DAL 中执行计算。举个例子，考虑一个带有摘要信息和行项目的发票系统：

因此，我在数据库查询中转换行项目的代码如下所示：

所以这是我的问题：考虑到我的 n 层架构，我的 DAL 是执行 InvoiceTotal 计算的正确位置吗？考虑到 BBL 的部分工作是执行计算，这是否违反了 DAL 和 BLL 之间的关注点分离？或者我是否过于从字面上理解了 BBL 执行计算的功能，如果需要这些计算来填充模型，可以在 DAL 中进行计算？我发现在 DAL 中进行 InvoiceTotal 计算很有吸引力的一个原因是因为我只需对发票项目记录进行一次迭代。如果我在其他地方创建了一个单独的 InvoiceTotal 函数来获取 InvoiceTotal，那么我将不得不再次遍历记录。

编辑：事实证明，真正的问题不是 DAL 中是否应该允许计算，而是 InvoiceTotal 是否应该在我的模型中。从数据库规范化的角度来看，它不是必需的，因为可以从行项目计算总数。在这种情况下，InvoiceTotal 不应该在我的模型中，而应该在我的 ViewModel 中，在这种情况下，不需要在我的 DAL 中进行计算。出于性能原因，我可以忽略数据库规范化问题，并在我的模型中包含 InvoiceTotal，但如果是这种情况，我会将 InvoiceTotal 持久保存到数据库中，在这种情况下，在填充我的模型时不需要计算，因为我只需从中提取值数据库。

经验教训：如果我想在 DAL 中进行计算，我的模型可能存在缺陷。

我正在使用 n 层方法构建 ASP.Net MVC Web 应用程序。我的结构如下所示：

我通常将计算放在业务层中，但是仅用于演示目的的计算呢？例如，在我的应用程序的一个视图中，我显示了发票总额、已付款项和欠款余额。欠款余额是计算出的金额。由于我在我的应用程序中多次使用 Balance Owing，我倾向于在我的 BLL 中创建一个通用的 BalanceOwing 方法，但在其他情况下，计算只会用于一个视图。在这种情况下，计算应该进入控制器还是在我的情况下进入映射层？（我有一个映射层，用于将域模型转换为视图模型。它使控制器更整洁）。

这真的是分界线吗？也就是说，如果我可以概括计算并多次使用它，它应该进入 BLL，但如果它特定于一个视图，它应该在控制器或映射器中？

概括：

我选择了@trailmax 的回答，因为他看到一些我认为是表示逻辑的东西实际上是业务逻辑，因此属于 BLL。如果某些东西确实是表示逻辑并且涉及诸如分页之类的计算，我会将它们放在@ramiramilu 提到的实用程序类或扩展方法中

我有一个 n 层应用程序，其中包括一个数据访问层 (DAL) 和一个业务逻辑层 (BLL)。我在 DAL 中使用 SQL 查询和存储过程来填充我的对象。

所以这是我的问题：

我的 SQL 查询中的子句是否ORDER BY违反了关注点分离？

一方面，排序逻辑似乎属于业务层，因为是我们的业务规则决定了我们为什么要以特定顺序显示数据。此外，我们可能希望以不止一种方式显示相同的数据。此外，我的数据访问代码不应该不知道诸如如何显示之类的问题吗？

另一方面，数据库在排序数据方面通常比应用程序代码更有效，因此出于性能原因，使用 ORDER BY 子句优于 BLL 中的排序。此外，我不确定在 DAL 中指定默认排序顺序是否真的违反了关注点分离。记录必须以某种方式从数据库中出来。为什么不根据最常见的情况对它们进行排序呢？如果我们需要不同于默认的排序顺序，那么我们可以通过 BLL 中的某种方法进行排序。

我一直在开发一个多层 MVC 应用程序，现在回顾一下我到目前为止所做的事情。尤其是现在我已经回去并再次阅读了有关多层/层的大量信息（那里有大量信息，但没有真正的一致性或标准），我现在正在质疑我的数据层。

我强烈怀疑我没有正确地实现它（符合良好的设计）并且可能已经偏离正题。这是我所做的：

网页界面

• 包括控制器、视图模型、视图

BLL

• 包括包含以下内容的服务类：

  1. 内存中的操作代码，例如集合...
  2. 数据访问代码，例如实体的 EF linq。

数据

• /Models 包含域类的文件夹
• /DAL 文件夹，其中包含 DbContext 类

...

退后一步，重新审查，这是我所看到的，也是我所质疑的：

1. 在 BLL 中，EF 代码在这里看起来不正确。它应该在数据层。有人可以确认吗？

2. 我的数据层（即数据项目）包含上下文类和域模型。我读过人们将他们的数据层分为 a) DAL 和 b) 模型。因此，我猜 DAL 层将包含上下文类和数据 (EF) 代码，而模型层将仅包含域模型。这最终会使您总共有 4 层。可能是太过分了还是设计不错？

3. 任何偏好在哪里使用 AutoMapper 进行 EF 到 ViewModel 映射？我目前正在 Web 层中进行映射，但怀疑它在 BLL 中可能更整洁。有些映射只能在 Web 层完成，例如下拉列表的 SelectListItem。

考虑以下内容：

我有一个带有字符串属性的模型，它只有一个 get 访问器，我们不希望直接设置该值。

该属性的值是在 BLL（一个不同的库）中计算的。

在不使用反射的情况下设置属性值的最佳方法是什么？

澄清一下，挑战在于 Name 值需要是不可变的。经常访问和修改相同的模型。我们不想冒险有人在事后为其赋值。我想我正在寻找一种最佳实践来保持不变性。