java服务写在哪里_在服务层Java Spring MVC中编写哪些函数或者要写的东西(Which functions or what things to write in service laye...

在服务层Java Spring MVC中编写哪些函数或者要写的东西(Which functions or what things to write in service layer Java Spring MVC)

假设我有class USER和属性。

在某些示例中，我看到为某些函数定义的UserService class 。

我很困惑应该在User Class中编写哪些东西或函数以及UserService中的哪些东西。

对于e，g如果我想写一些函数来验证数据库中的用户，比如

validate(user,pass)

哪里应该写那些功能

如果我有class ShoppingProducts

我希望得到特定用户购买的所有产品，我应该在哪个类中编写该函数，我的意思是在product class or UserService or ProductService

Suppose i have class USER with attributes.

In some examples i see UserService class defined for some functions.

I am confused which things or functions should written in User Class and which things in UserService.

For e,g If i want to write some function To Validate users in database like

validate(user,pass)

Where should write those function

Also if i have class ShoppingProducts

and i want to get all prodcuts shopped by particular user in which class should i write that function i mean in product class or UserService or ProductService

原文：https://stackoverflow.com/questions/5078890

更新时间：2020-02-13 19:42

最满意答案

这是领域模型与贫血模型的典型示例。

在这个讨论中有很多理论，但我的一个实际建议是：

将所有可以在User属性上操作的方法仅放在User类中。

在服务中放置所有需要数据库访问，访问Web服务或其他层的方法。

请参阅我的相关文章。

This is a typical example of domain model vs anemic model.

There's a lot of theory in this discussion, but a practical advice from me is to:

put all methods that can operate on the User properties only in the User class.

put all methods that require database access, accessing web services, or other layers, in the service.

See this related article of mine.

2011-02-22

相关问答

恕我直言，交易应该去服务层。 通常，一个业务事务包含多个查询和更新。 如果仅将@Transactional放置在DAO层上，则每个查询和更新都将在单独的事务中运行，这有效地破坏了事务的目的。 但是如果服务是@Transactional ，每个数据库交互都会加入一个在web层进入服务层时开始的主事务。 请注意，在这种情况下，如果Web层运行多个服务方法，它们中的每一个都将在单独的事务中运行(同一个问题将向上移动一级)。 但将@Transactional放置在Web层可能会引入意想不到的副作用，例如N

...

如果需要，可以直接创建没有Service接口的ServiceImpl，但不会显着提高速度。 然后，当数据访问更改时，您将处于不利地位。 创建服务层的主要原因是在更改数据访问时维护ServiceImpl。 If you want, you can directly create ServiceImpl without Service interface, but it's not increase the speed significantly. Then you get disadvantage

...

您可以将DAO的新实现标记为@Primary 。 表示当多个候选者有资格自动装配单值依赖项时，应该优先考虑bean。 如果候选者中只存在一个“主”bean，则它将是自动装配的值。 @Component

public class FooService {

private FooRepository fooRepository;

@Autowired

public FooService(FooRepository fooRepository) {

t

...

您应该使用HibernateTransactionManager而不是DataSourceTransactionManager。 使用

class="org.springframework.orm.hibernate5.HibernateTransactionManager">

代替

...

这是领域模型与贫血模型的典型示例。 在这个讨论中有很多理论，但我的一个实际建议是： 将所有可以在User属性上操作的方法仅放在User类中。 在服务中放置所有需要数据库访问，访问Web服务或其他层的方法。 请参阅我的相关文章。 This is a typical example of domain model vs anemic model. There's a lot of theory in this discussion, but a practical advice from me is

...

从技术上讲，DAO和服务层并不是MVC的“部分”。 它们是另一种称为服务层模式的模式，它存在于服务器上并支持控制器或其他类的操作： 客户端----控制器 - | - 服务---- DAO MVC模式--------- | ----服务模式 https://martinfowler.com/eaaCatalog/serviceLayer.html 简而言之，您可以将MVC视为将客户端和service / dao层的操作封装为封装服务器上的操作的模式的模式。 他们一起工作，但没有一个是另一个的一部分。

...

我想这更像是一种哲学而非编程。 例如，您有用户登录系统。 当您尝试获取用户详细信息userService.getDetails(userId) ，您应该抛出异常(因为您没有记录使用而没有关于他的额外数据) - 这是错误。 但是如果你试图让他的朋友获得userService.getFriends(userId) ，那么如果没有任何给定id的记录就可以了。 所以在这种情况下，Optional是很好的响应。 我想是这样的。 I guess this is more a matter of philoso

...

传递不同的对象不会使您的服务有状态。 考虑这个例子。 @Service

Public class JobService {

private Job currentJob;

public void setJob(Job job) {

currentJob = job;

}

public void run(){

-- perform the business logic on currentJob

}

}

这会使bean“有状态”并导致无法解释的行为。 多个

...