问题标签 [business-logic-layer]

我正在构建一个中等规模的系统，我面临的问题可能是你们中的一些人以前遇到过的。在我的业务层中，我返回具有对该业务方法重要的属性子集的业务对象，我很担心，因为我最终可能会得到很多名称无意义的对象，或者只有一个对象，其中只有一个属性子集被填充到给定的方法。让我举个例子。

情况1

例如，一个用户属于一个城市，它又属于一个州和一个国家，, User,City是我的数据库中包含很多字段的表，但我想要一个包含订单列表的用户列表，所以我创建一个名为例如仅具有重要属性 ( ) 的业务对象，我的 DAL 仅从数据库中检索该字段。StateCountryUserWithOthersUserId, UserName, CityName, StateName, CountryName, List<Order>

案例2

我现在想返回一个带有订单数量的用户，我在我的业务对象（UserId, UserName, CityName, StateName, CountryName, OrdersCount）中以以下字段结尾，并且可以调用该类，例如UserWithOrderCount

我曾想过一些选择：

1. 制作这两个业务类并在每个 DAL 方法中分别填充它们（这个对象很简单，但考虑到该方法可能有一个复杂的选择查询，需要封装以供重用，因此存储库模式在这里不太适合，至少我认为）。
2. 只创建一个User具有所有属性的UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>对象（所有耦合。
3. 如果我稍后在另一个视图中需要，选项 1 不能很好地处理，两者List<Order>和OrdersCount属性。
4. 现在考虑一下，如果您使用 ASP.NET MVC 良好实践告诉您需要一个 ViewModel 来传递给视图，我想从我的 Businnes 层返回 ViewModels，但我认为这不是一个好主意，感觉就像我是违反某些东西，也是不可能的，因为我的业务层在另一个程序集中而不是 Web 应用程序中。
5. 我不想一遍又一遍地编写相同的 Linq 查询，但如果使用 NHibernate 或 EFCodeFirst 是“喜欢”选项之一，我将需要创建大量小型业务对象。

你如何处理这种情况？我认为这是一个高级别的设计决策。

我负责支持使用 BusinessObjects（不包含逻辑，仅包含属性）的 C# Winforms 应用程序和带有操纵这些实体的类（“Helpers”）的 BusinessLayer。

问题：您是否应该将 BusinessObject 传递给 Helpers 构造函数，然后在构造函数中实例化 Helper 的可公开访问的 Entity 变量，或者您是否应该只将 Entity 传递给对其进行操作的方法？

场景一：构造函数

场景 2：作用于实体的方法

我在场景 1 中遇到的两个主要问题： A) 下一个开发人员必须深入研究 CarHelper 类才能意识到它有一个公共 Car 访问器属性，它在需要它的方法中引用该属性。这进一步混淆了 Helper 类，因为每个方法在执行其职责之前都需要检查“null” Car 属性... B) 如果在操作之间存在大量其他代码，则可能会不清楚 ch.Wash( ) 实际上是在做...它是否甚至对 Car 对象起作用...？

大家怎么看？？？

与实体合作时，建议使用以下哪项？（以下代码在 UI 层。UserManager在业务层）

1-

在用户管理器中：

2-

在用户管理器中：

假设我有两个实体：User和UserGroup。
它们具有一对多的关系 => 每个UserGroup实际上包含 0 到 n 个用户。

如果我想UserGroup在我的业务层中检索用户的位置将是一个更好的类来放置该方法？

1. 中UserManager，添加方法：GetAllUsersForUserGroup
2. 在UserGroupManager添加上述方法。

猜猜2更好。但我不确定。
谢谢。

更新
猜猜我无法完全解释我的意思。
是的，我们可以有User, Users, Group,Groups等。

但我并不是想找出可以应用哪些不同的模式等来实现业务。我的问题是：你是投入GetAllUsersForUserGroup(int UserGroupID)还是UserManager投入GroupManager？您认为GetAllUsersForUserGroup(int UserGroupID)应该在管理用户的类中还是在管理用户组的类中定义？

我有一个带有表示层和业务层的 Web 应用程序作为单独的项目。一个是 Web 应用程序，另一个是类库。我添加了对 Web 应用程序的 Web 引用以使用 Web 服务。我在使用服务 API 时没有遇到任何问题，但我发现自己在我的表示层中添加了很多业务层类型逻辑来利用这个 API。如果我可以更改我的一些业务层代码以使用 Web 服务，我会很高兴的，但是这样的配置听起来像是一个大循环，不。无论如何，我希望我的对象能够继续做他们正在做的事情，但它也可以与 web 服务一起使用，但我发现自己必须在我的表示层中创建一个 helper/manager 类来使用 web -服务。这导致我在对要通过服务添加的对象执行操作的任何地方都需要更改代码。解决这个问题的正确方法是什么？

我什至不确定在所有漫无边际的任何地方都有一个合理的问题，但如果有人能提供任何有用的话，我将不胜感激。

谢谢！！

我已经阅读了 Async Page 及其用法，看起来很简单：

[更新]取自这里：

但我无法解决以下问题：

如果我想从我的业务层而不是直接从我的页面的代码隐藏调用异步操作/Web 服务怎么办？我似乎无法在网上找到任何关于此的信息。

简而言之，场景：

Request--> Page handler--> Business layer service- || ->External webservice

我能想到的问题的一种解决方案是异步调用业务层服务，仅在调用外部 Web 服务所需的时间内使用线程池中的第二个线程： Request--> Page handler- || -> Business layer service- || -> External webservice。[更新->]所以基本上我想使用完全相同的模式将上述方法扩展到我的业务层服务。[<-结束] 在这种情况下，两个线程都将被释放到线程池（或者我猜是这样），并且可以处理其他传入的请求。当 webservice 的应答返回时，首先会绑定一个线程来处理业务层服务，然后再绑定一个线程来完成 Page 渲染。但这听起来像是很多开销——无论是在编码方面，甚至在运行时。

另一种解决方案是对第一个解决方案的修改 - 即，一旦我们触发外部 web 服务调用并在应用程序内部而不是在请求的上下文中处理它的结果，就会向客户端返回一个未完成的响应。然后，当然，客户端必须轮询服务器以获取应该保存在某处的结果。这基本上是 @emfurry 在Async Web Service Calls中提出的想法。

我还没有考虑过其他可行的选择吗？

我在许多书籍中读到，在分层架构中，一个层应该只使用它下面的层提供的服务。企业应用程序中常用的层有：

1. 介绍
2. 商业
3. 持久性

这意味着业务层的服务（包含业务逻辑）应该只访问持久层提供的服务。

我有一个向用户发送消息的 MessageService。每当对象的状态发生重大变化时，必须通知所有关联的用户该变化。这意味着识别更改的业务层服务必须使用 MessageService 发送消息。但是 messageService 本身就在业务层，因此同一层的其他服务不应访问它。

那么如何在不违反代码架构的情况下使用MessageService呢？

现在我正在研究一个用 VB6 开发的大型银行解决方案。该应用程序大量基于表单，缺乏分层架构（所有用于数据访问、业务逻辑和表单操作的代码都在单个表单类中）。我现在的工作是重构这段代码。我正在用 C# 编写适当的业务逻辑层和数据访问层，表单将保留在 VB 中。

以下是代码片段：

District Entity 类，为什么它的扩展名是 DAO，我不清楚。

DistrictGateway 类负责数据库查询处理 现在是业务层。

这是业务层的代码。

我的问题是：

1. 这是一个完美的设计吗？
2. 如果没有，这里有什么缺陷？
3. 我认为，这段代码带有重复的 try catch 块
4. 这个实现有什么好的设计

我去面试了，被要求展示我的业务层架构。我对 3 层架构有一些想法，但真的不知道在面试官面前写什么。所以假设我的项目涉及一个组织的员工，那么我会在那里写什么。它会是我应该制作的任何类型的图表还是一些编码部分。我在 C# 框架 3.5 中工作。我真的不明白这个问题还有什么要说的，所以如果需要的话，请告诉我。谢谢。

编辑 我在winforms工作。我知道业务层是什么，但不知道该告诉面试官什么，因为业务层有代码，显然我的项目有点大，所以代码数量很大。那我应该在那里写什么？

CakePHP 似乎从未提及分离应用程序的业务逻辑和数据访问层。这是我的第一个 MVC 应用程序，我的“胖模型”变得非常胖，因为它们包含各种业务逻辑，其唯一共同点是需要访问同一个数据库。

当您听到将业务逻辑从控制器移到模型中的建议时，以这种状态结束真的可以接受吗？CakePHP 是否为单独的业务逻辑层提供任何结构作为其框架的一部分？

谢谢，布赖恩