我应该将 BLL 方法直接调用到我的 Asp.Net MVC 3 控制器中吗？

Posted 2023-02-24

【中文标题】我应该将 BLL 方法直接调用到我的 Asp.Net MVC 3 控制器中吗？

【英文标题】：Should I call BLL methods directly into my Asp.Net MVC 3 Controller?

【发布时间】：2011-11-17 01:55:18

【问题描述】：

我有一个在其他几个应用程序中使用的业务对象层，我想在我的 MVC 应用程序中使用它。我的担忧更多是设计方面的问题：有以下内容是否正确：

using Interface.MyOtherProject
public class MyMVCController: Controller

    [HttpGet]
    public string GetSomethingById(Int32 id)
    
        return new javascriptSerializer().Serialize(MyObject.GetById(id));
    

所以问题是我可以这样做吗，我应该在模型中执行此操作并直接从模型返回此字符串，还是应该将我的 BLL 重写到我的模型中。我阅读了一些类似问题的答案，但我仍然不清楚我是否可以（而不是我应该或不应该）。我不想打破这种模式，因为我将向学校里的一些同伴展示这个项目。

感谢您的帮助！

汉莱特

【参考方案1】：

当我们不得不面对这个决定时，我们开始创建封装/镜像我们的业务对象的视图模型。这让我们可以更好地控制对象在 json 中序列化时的外观，而无需在我们的业务层中添加视图逻辑。

示例：假设我们有一个 Person 业务对象：

public class Person

  public int Id get;set;
  public string Name get;set;

当客户端要使用我们的 Web 服务时，我们不希望他们知道 Id 的值是什么，因为这是一个内部数据库键。我们考虑修复的两个选项是 1) 将 [ScriptIgnore] 属性添加到 Person.Id 属性或为我们的 Person 创建一个单独的视图模型，该模型是为视图域定制的。

我们远离选项 1，因为我们不想在业务层中添加视图逻辑，原因与您不希望的很多相同......我们的业务层不直接绑定到我们的表示层。

这是一个非常简化的场景，但更大的想法仍然完好无损。使用单独的视图模型，您可以在视图中包含/排除数据，而不会影响业务层的整洁。

【讨论】：

感谢您的帮助。这行得通吗？ public List<SelectListItem> MyMethodName(Int32 Id) List<SelectListItem> items = new List<SelectListItem>(); foreach (MyObject obj in MyObject.GetById(Id)) items.Add(new SelectListItem() Text = obj.NameProperty, Value = obj.ValueProperty.ToString() ); return items; 这样我就镜像了我的业务对象，并且当我将其序列化为 JSON 时，我并不关心直接来自我的实际业务对象的属性名称谢谢！

抱歉格式错误。我不知道如何格式化这里的代码。

看起来您正试图将您的 MyObject 类序列化为键/值对...在这种情况下，您最好返回字典，如下所示：@987654327 @ 如果这个特殊情况满足您的所有需求，那么我不会提出合适的建议，但它仍然围绕着为您的表示层使用视图模型的真正价值。我想这种方法如果被普遍应用，当涉及到更复杂的对象序列化时会变得很棘手。

明白了！非常感谢我的朋友。尽管在这种特殊情况下，我确实需要一个 SelectListItem 对象，它具有可以在我的视图中使用的“Selected”属性（我现在只是填充 Dropdowns）。你和大卫一样帮了大忙。谢谢你们！

【参考方案2】：

我在这里没有看到任何明显的设计问题。要解决问题中的一个特定点：

我是否应该在模型中执行此操作并直接从模型中返回此字符串

你的意思是模型应该提供 JSON 序列化的字符串吗？我会说不。该模型只是业务概念的表示，并包含作用于该概念的逻辑。 JavaScriptSerializer 基本上是在创建该模型的视图。它是 UI 逻辑，并且在演示代码中属于它所在的位置。模型不应该关心它被如何看待，它只关心它所代表的状态。

我应该将我的 BLL 重写到我的模型中

我不确定你在这里问什么。模型应该包含业务逻辑，这是肯定的。如果您的 BLL 只是一堆将模型用作裸 DTO 的实用方法，那么您可能需要考虑将业务逻辑移入模型本身。但是这里给出的代码很难判断。

当我看到MyObject.GetById(id) 时，我认为GetById 只是MyObject 模型上的一个静态工厂方法，它调用它需要的任何依赖项，例如DAL 存储库（可能通过其他方式而不是参数提供给方法，但希望不会在内部实例化），并返回一个 MyObject 的实例，这看起来不错。我自己也经常使用相同的模式，偶尔会尝试如何命名这些方法以使整个事情更加流畅。

【讨论】：

感谢您的回答。正如我提到的，我确实在其他一些项目中使用了 BLL，所以它不是一堆实用方法，但实际上我有我的 DAL 和业务逻辑（我使用企业库），所以移动是不切实际的将整个 BLL 放入我的模型中。我所说的“我是否应该将我的 BLL 重写到我的模型中”的意思是我是否应该将我的所有实体创建到我的模型中并从 BLL 中包装它们的所有方法和属性。再次感谢。

@Hanlet：很有趣。我很想看看代码，看看它是如何组织的，但我认为在 Stack Overflow 上没有合理的格式。就高级一般建议而言，我建议不要在同一代码中同时使用 DAL 和业务逻辑。适合我的一种方法是创建我的域模型和任何服务类（或外部实现的依赖类的接口）以仅包含业务逻辑。我的 DAL 通常最终成为我的模型内部使用的另一个项目中的一系列存储库。

@Hanlet：这个想法是模型不应该知道或关心域模型之外的任何事情。然后应用程序只是与模型交互，不知道也不关心 DAL 或类似的东西。 DAL（和其他基础设施依赖项）只实现域接口，所有需要依赖项的代码都是针对这些接口编写的，并且 IoC 框架会注入实现。

大卫，再次感谢您花时间回答我的问题。我组织 BLL 的方式是使用 Active Record 模式，并使用 Enterprise Library Data Application Block。所以我几乎可以说他们在一起，但他们不是（我在这里可能错了）。我曾经在一家使用快速应用程序开发的公司工作，这（我们发现）是开发应用程序的最快方式（当然是通过 ORM）。我会接受你的建议。非常感谢您的帮助！