问题标签 [business-logic-layer]

我有一个为成员进行复杂计算的应用程序。每个成员可以将多个美国州与他们的个人资料相关联。每个州对成员完成的每门课程都有不同的计算。

到目前为止，我一直在数据库（SQL Server 2008）中执行计算，然后将数据发送回应用层，在那里他们可以查看他们的历史记录，然后为每门课程下载证书。

我有一个业务逻辑层，但那里发生的事情并不多。我知道这已经被问了很多，但你认为我应该在哪里执行这些计算：业务层还是数据库？我来回走！！

我正在用 Go 编写一个 Web 应用程序。到目前为止，我已经编写了我现在需要的所有基础库，而且效果非常好。包结构在这方面非常方便。

现在我需要开始编写应用程序本身，即业务逻辑。我对这段代码应该如何或去哪里有点迷茫。

我已经在官方文档页面上观看并阅读了几乎所有应用程序开发教程/演练，他们总是在main包/命名空间中编写整个域逻辑。

这是要走的路（对不起，不得不这样做）还是只是为了简单起见？

在我看来，将业务层放入包中感觉不舒服。

我有一种情况，我想使用单个业务逻辑类对各种实体框架类执行类似的操作。我已经定义了一个接口，这些类在部分类文件中实现。

但是，当我尝试针对这些接口方法编写 LINQ 到实体查询时，我得到了 NotSupportedException，因为查询不是直接使用类的属性，而是通过接口。

我想把繁重的工作交给数据库层，那么有没有办法在不使用 LINQ 对象的情况下实现这一点？

这是一些演示我的问题的代码（它使用由工厂创建的通用存储库类）。

我正在为互联网用户提供一些服务的互联网网站上工作。所以我们有一个管理系统，我的业务团队的合作者可以在其中获得他们想要的信息，例如最近 3 天内注册了多少新用户？或者发表了多少带有“笑话”标签的文章等。因此在管理系统中，有几个页面用于搜索一些带有条件的表格。这些页面非常相似：

用户ID：[--------------] 昵称关键字：[------------] 注册时间：[BEGIN]~[END] [搜索]

搜索结果在此处列出

该类User具有更多的属性，而不仅仅是 UserID/Nick/RegisterTime（以及用户表），但只有 3 个属性被视为条件。所以我有一个UserSearchCriteria像这样的课程：

然后在数据访问层，search 方法接受一个带有其类型的参数UserSearchCriteria，并构建对应Expression<Func<User, bool>>的查询。而在DAL之外，其他开发者只能通过条件提供的3个条件搜索用户表，例如，他们无法搜索City属性为“纽约”的用户（这通常是因为该属性在DB，用它搜索很慢）。

问题1：这种封闭搜索的实现是否正确？有什么建议么？

问题2：现在我在项目中发现了更多的标准类，比如ArticleSearchCriteria，FavouriteSearchCriteria等等，我认为未来标准会越来越多。它们具有几乎相同的工作机制，但我需要重复代码。有更好的解决方案吗？

PS如果你需要这些信息：jQuery + ASP.NET MVC 3 + MongoDB

我查看了标题相似的问题，但没有成功。我可以从业务层创建服务引用以从另一个业务实体中提取数据吗？还是应该从服务层完成？

一个类是否有一个标准名称来表示另一个类，但要保持不同；

一个例子应该有助于说明：假设我的业务层可以访问一个类对象，例如 .NET 的 System.Diagnostics.Process，其中包含有关系统上运行的进程的大量信息。另一个项目，例如系统资源项目，对所有这些信息没有用处，因此在业务层中，我实现了一个 ProcessInfo 类，它只包含被认为重要的属性。

这种中间的、有代表性的班级有名字吗？

我用的是ADO.NET，我已经创建了DAL和BAL，结构如下

我将使用服务公开 BAL。Web、Window、Mobile 等多个应用程序将使用此 BAL。

我不确定 Sql Transactions 应该从哪里开始。谁负责创建复杂的实体。

例如，复杂实体可能是

现在谁应该创建一个实体？它是 BAL 还是 DAL。SqlTransactions 应该从哪里开始？我应该如何使这些实体支持延迟加载，因为我是存储过程的支持者，并且更喜欢每个请求使用一个数据库连接

我有一个实体框架 4 的 n 层应用程序设计问题。

在服务器端，我的应用程序有 3 层： - 一个服务层 (WCF) - 一个业务层 - 一个数据访问层（使用 EF4）

实体是 POCO，放置在独立的项目/程序集中。

我使用依赖注入来创建业务对象和数据访问层，因此我只使用接口，并且我的业务层不依赖于 EF。

我想使用 EF Compiled Queries 来提高性能。

但是我的（业务）查询是在业务层中定义的，因为在我的架构中，DataAccess 仅提供 CRUD 方法。

所以编译的查询应该在业务层中定义，但我对 EF 没有依赖，也不希望保持松耦合，因此，我不能从那里调用 ObjectContext。

在 DataAccess 中定义查询不适合我的应用程序设计。

那么有谁知道是否有一种通用的方法可以将业务查询从业务层注入到 DataAccess 层，以便我可以将它们与编译查询一起使用？

我已经尝试了很多东西，到处看了看，但找不到答案…… :( 看起来 EF 不适合那种 n 层应用程序。

我有 2 个非常相似的 sql 表。每个表只有外键不同。

当我选择 2 个内容几乎相同的表时——只是 FK 不同——你真的在你的服务和数据提供者中创建了你的 CRUD 方法的副本（使用 ado.net pure）吗？

如何改进服务，以便在服务和数据提供者类中只使用一种 Get/Add/Update/Delete 方法？我也不想进行重复的单元测试...

更新：

到目前为止，这是我的解决方案：

我在 BLL 和 DAL 中的 Get/Add/Delete 方法获得了一个 UnitDTO 对象，其中包含所需的所有信息。

那么一个缺点可能是 - 如果这个项目将在一个团队中完成 - 当您创建 UnitDTO 并将其传递给每个 CRUD 方法的 BLL 时，您必须知道在 DAL 中使用/需要哪个变量。

你怎么看？

（请记住，我是一个相对缺乏经验的程序员。我知道这个问题可以被视为过于开放，因为在 OOP 中有很多关于继承的哲学。这个问题更多地针对我的思考过程，即，我是否以经验丰富的程序员认为正确的方式处理这种情况？我的想法显然是准确还是不准确？）

我正在设计一个库存系统来跟踪有关 IT 硬件的信息，包括计算机、打印机、交换机、路由器、移动电话、硬盘驱动器和其他设备。我设计了一个数据库，现在正在规划一个前端应用程序。我打算让应用程序使用数据访问层、业务逻辑层和业务实体。我仍处于概念规划阶段，我意识到此时我不应该考虑实施细节，但我的思想倾向于向前推进。搜索功能的工作方式应该是：用户输入搜索条件并执行搜索。返回匹配设备（或唯一匹配设备）的列表。设备列表显示在某种类型的列表视图中，当设备被选中时会显示设备的详细信息视图。

我一直想知道在我的最终业务实体中使用继承是否会使我的应用程序受益，或者它是否会增加不必要的复杂性......或者它是否完全错误。我最初的想法是如图所示的设置：

（这不是实际设计，只是本文的简化概念）除了每个设备具有特定于类型的属性外，任何设备在任何给定时间都可以处于两种状态之一，活动或存档。我根本不知道如何建模。

我开始考虑使用此设置时查询可能如何工作。从数据访问层查询设备的任何特定子类似乎很简单，例如

伪代码：

导致我写这个问题的问题是如何处理诸如“从特定位置获取所有设备”之类的查询。

如果我有基类对象引用，我将如何显示基本设备详细信息和特定设备详细信息？（尽量避免疯狂的投射或使用反射）。该位置的每个设备都将缺少其子类型的特定属性。如果我想显示有关特定设备的所有数据，我将不得不再次查询数据库以获取剩余字段。必须执行另一个查询是设计不佳的标志吗？此外，我将如何确定正确的设备类型？可能有一个大的 switch/case 语句测试每个Device.Type属性，执行正确的查询，返回完整的子类型并向用户显示详细信息？或者......返回包含完整子类型对象的单独列表然后遍历所有列表以在列表视图中显示公共属性然后在详细信息视图中轻松显示子类型详细信息是否更好？

这是一个有用的继承案例还是我滥用它？我目前正遭受信息过多的问题。我阅读了有关 OOD 的所有可能内容，并且我脑子里有很多规则和指导方针，我不知道我做的是否正确。我觉得我的大脑正在寻找应用我一直在吸收的信息，所以我在想象一个不正确的实现。我一直在考虑所有这些关于从编程到抽象的业务以保持代码的灵活性，但在某些时候你需要处理具体的类，对吧？从我的角度来看，继承是关于行为而不是属性。由于我实际上并没有对任何行为进行建模（或者我和我只是看不到它？）并且只是收集有关设备的数据，因此我很难解释它们的关系。由于这些类本质上是属性的愚蠢集合，我觉得它们都应该是单独的类。再说一次，我将在所有类中都有重复的字段，但在这种情况下真的很重要吗？

我知道有很多关于 OOD、继承、组合等方面的书。我读过其中的一些书；我目前正在阅读更多内容，并且我花了几天时间在线研究。每个人都方便地使用明显的继承示例。我正在做关于水果、动物和形状示例的噩梦。

感谢您花时间阅读我的问题，并感谢您提供的任何信息或见解。请随时提供任何其他提示、见解、商业秘密、埋藏宝藏地图、适合航海的船和六分仪，或任何您认为可能有帮助的东西。