哪个是更好的类设计:页面调用类和页面调用BLL或类调用BLL?

时间:2022-02-16 20:07:13

If I have an object, say, a user class, with say First & Last Name properties what is a better way to populate it:

如果我有一个对象,比如说是一个用户类,说具有First&Last Name属性,那么填充它的更好方法是什么:

  1. The PAGE instantiates the class and the PAGE calls the business layer to popualte the class. (In this case the class is essentially a container for data).
  2. PAGE实例化类,PAGE调用业务层以使类变为popualte。 (在这种情况下,类本质上是数据的容器)。

or

  1. The class itself not only has the properties, but it also has a method to call the business layer, populate itself and return itself populated to the page.
  2. 类本身不仅具有属性,而且还有一种方法来调用业务层,填充自身并返回填充到页面的自身。

7 个解决方案

#1


I'd go for the former. I think it's cleaner, and that way your User class can stand on its own, even if the business layer changes.

我会选择前者。我认为它更干净,即使业务层发生变化,您的User类也可以独立存在。

Note, also, that the former would seem more conducive towards using a 3-tiered MVC architecture as well.

另请注意,前者似乎更有利于使用3层MVC架构。

#2


It really depends on what you are going to use that class for. Is it only ever going to be a container that you populate and use for display? Are you going to be modifying that data and using it to update your database?

这实际上取决于你将要使用的课程。它是否只是一个容器,你填充并用于显示?您是要修改该数据并使用它来更新数据库吗?

Basically what you are looking at is the DAO/DTO set of functionality. In case #1 you are talking about a data transfer object (DTO) it's just a container for the data. In case #2 you are talking about a data access object (DAO) it's an object that understands how to persist your data and where to get it from.

基本上你正在看的是DAO / DTO功能集。在#1的情况下,您谈论的是数据传输对象(DTO),它只是数据的容器。在#2的情况下,您谈论的是数据访问对象(DAO),它是一个了解如何持久保存数据以及从何处获取数据的对象。

What you are missing is a case #3 which is a business object that understands the business logic associated with your data. i.e. what permissions does my user have, what is my users position within the company (assuming a business user).

您缺少的是案例#3,它是一个了解与您的数据相关的业务逻辑的业务对象。即我的用户拥有什么权限,我的用户在公司内的位置(假设是业务用户)。

Unfortunately there is no one correct answer, it all depends on what you are trying to build.

不幸的是,没有一个正确的答案,这一切都取决于你想要建立什么。

#3


I prefer the former. With the latter you end up forcing dependencies in the weirdest places.

我更喜欢前者。使用后者,您最终会在最奇怪的地方强制依赖。

#4


I'd suggest reading up about the factory method and abstract factory patterns, with a view to delegating creation of the class to something other than the class or the page. Here's why:

我建议阅读有关工厂方法和抽象工厂模式的信息,以便将类的创建委托给除类或页面之外的其他东西。原因如下:

The page is focused on page stuff - it only cares about something that holds a first and last name, not the type of class. Therefore, it shouldn't create the class, just ask for an implementation. The page only really cares about an interface, with maybe firstname and lastname properties, and maybe a save() method.

该页面专注于页面内容 - 它只关心具有名字和姓氏的东西,而不是类的类型。因此,它不应该创建类,只是要求实现。该页面只关心一个接口,可能是firstname和lastname属性,也许是一个save()方法。

If the class knows about the specifics of the business layer, you have dependencies you don't need. To change the business layer, you'd have to change the class internals or change the page so it creates a different class. If you did that for many classes, changing the business layer would require many changes in the class and/or page layers.

如果类知道业务层的细节,则您具有不需要的依赖关系。要更改业务层,您必须更改类内部或更改页面,以便创建不同的类。如果您为许多类执行此操作,则更改业务层将需要在类和/或页面层中进行许多更改。

#5


I would have an abstract superclass for all the business objects implement a reloadData() method. It can be tested separately from the web environment, and the web environment does not depend on the data layer.

我将为所有业务对象实现一个抽象超类实现reloadData()方法。它可以与Web环境分开测试,Web环境不依赖于数据层。

#6


The way I look at it is you have to have separation of concerns. Testing is much easier too when you have less dependencies. I would use the first method.

我看待它的方式是你必须分离关注点。当您具有较少的依赖性时,测试也会更容易。我会使用第一种方法。

#7


What about if the object has a .Save() method that calls the Business.Save() method?

如果对象有一个调用Business.Save()方法的.Save()方法怎么办?

Perhaps this is mixing it up too much though.

也许这是混合太多了。

#1


I'd go for the former. I think it's cleaner, and that way your User class can stand on its own, even if the business layer changes.

我会选择前者。我认为它更干净,即使业务层发生变化,您的User类也可以独立存在。

Note, also, that the former would seem more conducive towards using a 3-tiered MVC architecture as well.

另请注意,前者似乎更有利于使用3层MVC架构。

#2


It really depends on what you are going to use that class for. Is it only ever going to be a container that you populate and use for display? Are you going to be modifying that data and using it to update your database?

这实际上取决于你将要使用的课程。它是否只是一个容器,你填充并用于显示?您是要修改该数据并使用它来更新数据库吗?

Basically what you are looking at is the DAO/DTO set of functionality. In case #1 you are talking about a data transfer object (DTO) it's just a container for the data. In case #2 you are talking about a data access object (DAO) it's an object that understands how to persist your data and where to get it from.

基本上你正在看的是DAO / DTO功能集。在#1的情况下,您谈论的是数据传输对象(DTO),它只是数据的容器。在#2的情况下,您谈论的是数据访问对象(DAO),它是一个了解如何持久保存数据以及从何处获取数据的对象。

What you are missing is a case #3 which is a business object that understands the business logic associated with your data. i.e. what permissions does my user have, what is my users position within the company (assuming a business user).

您缺少的是案例#3,它是一个了解与您的数据相关的业务逻辑的业务对象。即我的用户拥有什么权限,我的用户在公司内的位置(假设是业务用户)。

Unfortunately there is no one correct answer, it all depends on what you are trying to build.

不幸的是,没有一个正确的答案,这一切都取决于你想要建立什么。

#3


I prefer the former. With the latter you end up forcing dependencies in the weirdest places.

我更喜欢前者。使用后者,您最终会在最奇怪的地方强制依赖。

#4


I'd suggest reading up about the factory method and abstract factory patterns, with a view to delegating creation of the class to something other than the class or the page. Here's why:

我建议阅读有关工厂方法和抽象工厂模式的信息,以便将类的创建委托给除类或页面之外的其他东西。原因如下:

The page is focused on page stuff - it only cares about something that holds a first and last name, not the type of class. Therefore, it shouldn't create the class, just ask for an implementation. The page only really cares about an interface, with maybe firstname and lastname properties, and maybe a save() method.

该页面专注于页面内容 - 它只关心具有名字和姓氏的东西,而不是类的类型。因此,它不应该创建类,只是要求实现。该页面只关心一个接口,可能是firstname和lastname属性,也许是一个save()方法。

If the class knows about the specifics of the business layer, you have dependencies you don't need. To change the business layer, you'd have to change the class internals or change the page so it creates a different class. If you did that for many classes, changing the business layer would require many changes in the class and/or page layers.

如果类知道业务层的细节,则您具有不需要的依赖关系。要更改业务层,您必须更改类内部或更改页面,以便创建不同的类。如果您为许多类执行此操作,则更改业务层将需要在类和/或页面层中进行许多更改。

#5


I would have an abstract superclass for all the business objects implement a reloadData() method. It can be tested separately from the web environment, and the web environment does not depend on the data layer.

我将为所有业务对象实现一个抽象超类实现reloadData()方法。它可以与Web环境分开测试,Web环境不依赖于数据层。

#6


The way I look at it is you have to have separation of concerns. Testing is much easier too when you have less dependencies. I would use the first method.

我看待它的方式是你必须分离关注点。当您具有较少的依赖性时,测试也会更容易。我会使用第一种方法。

#7


What about if the object has a .Save() method that calls the Business.Save() method?

如果对象有一个调用Business.Save()方法的.Save()方法怎么办?

Perhaps this is mixing it up too much though.

也许这是混合太多了。