Class 哪个类设计更好：页面调用类，页面调用BLL，还是类调用BLL？

如果我有一个对象，比如说，一个用户类，带有名字和姓氏属性，那么填充它的更好方法是什么：

该页面实例化该类，并调用业务层来popualte该类。（在这种情况下，类本质上是一个数据容器）

或

类本身不仅具有属性，而且还具有一个方法来调用业务层、填充自身并将填充的自身返回到页面

---

我会选择前者。我认为它更干净，这样您的用户类就可以独立运行，即使业务层发生了变化

---

另外，请注意，前者似乎更有利于使用三层MVC体系结构。

我更喜欢前者。对于后者，您最终会在最奇怪的地方强制依赖

我将为所有业务对象提供一个抽象超类，并实现一个reloadData（）方法。它可以与web环境分开进行测试，web环境不依赖于数据层。

我的看法是，您必须分离关注点。当依赖关系较少时，测试也会容易得多。我将使用第一种方法。

这实际上取决于您将使用该类做什么。它是否只会成为一个您填充并用于显示的容器？您是否要修改该数据并使用它更新数据库

基本上，您看到的是DAO/DTO功能集。在案例1中，您谈论的是数据传输对象（DTO），它只是数据的容器。在案例2中，您谈论的是数据访问对象（DAO），它是一个理解如何持久化数据以及从何处获取数据的对象

您缺少的是案例3，它是一个理解与您的数据相关联的业务逻辑的业务对象。i、 e.我的用户拥有什么权限，我的用户在公司中的职位是什么（假设是业务用户）

---

不幸的是，没有一个正确的答案，这完全取决于您试图构建的内容。

我建议阅读工厂方法和抽象工厂模式，以便将类的创建委托给类或页面以外的其他对象。原因如下：

页面主要关注页面内容——它只关注包含名字和姓氏的内容，而不关注类的类型。因此，它不应该创建类，而应该请求实现。页面只关心一个接口，可能有firstname和lastname属性，也可能有save（）方法

---

如果类知道业务层的细节，那么您就有了不需要的依赖项。要更改业务层，您必须更改类的内部结构或更改页面，以便创建不同的类。如果对许多类执行此操作，则更改业务层将需要对类和/或页面层进行许多更改。

如果对象具有调用business.Save（）方法的.Save（）方法，该怎么办

---

不过，这可能是把它混合得太多了。

选项3：页面调用业务层，返回预先填充的类实例。