服务层应该将对象还是id作为输入？应该是对象吗？

我有一个相当熟悉的设计，我有一个每个模型的DAO，然后是一个使用DAO并拥有所有业务逻辑的模型服务类。服务层应该将对象还是id作为输入？应该是对象吗？

我对如何正确创建这些服务类有点困惑，特别是我的参数应该如何，我的回答是什么样的。假设我有一个JSON动作，我可以读取JSON，然后加载我需要的对象，然后将这些对象传递给服务，或者我可以简单地传入ID，然后在服务方法中加载对象。

令人困惑的是，我可能会在控制器动作中执行一些这些操作，或者我可能会在服务层中执行这些操作。这些类型的问题是否有明确的答案？

伪代码如下：

UserDao 
    save 
    update 
    delete 
    getById 

UserService 
    private userDao 

    GetUser 
    Update

我会用我的服务层同时在Web应用程序和API层。

我能有这样的方法：

def GetSomething(userId: Int, locationId: Int, ...): Something = { ... }

我也可以把它想：

def GetSomething(request: GetSomethingRequest): GetSomethingResponse { ... }

它是一个或另一个，或者我应该都混？

来源

2015-11-04 Blankman

有趣的问题。 API层是什么？路线或控制器？为什么你将它与Web应用程序区分开来？ – Kris

您是否在寻找特定于scala和play框架的思想和想法，还是更一般的？ –

首先，我认为使用情况类IDS是一个不错的德兴等都将采用UserId(id: Int)和LocationId(id: Int) 比方说你有一个这样的模式：User(id: UserId, locations: Set[Location])

然后让说，你想成为像/user/1/location/1 要求你控制器需要通过返回Location json来处理这个问题。为了做到这一点，你需要 1.查找ID User（可能不存在 - > NOTFOUND（带ID用户）） 2. User找到Location（可能不存在 - > NOTFOUND（位置与ID）

考虑到所有这些因素，你需要一个服务：def find(userId: UserId):Option[User] = {...}然后在您的User添加功能找到的位置：高清findLocation（ID：LocationId）：选项[位置]把 findLocation在User防止所谓的“贫血模型'

更新的东西有点不同。你的Location可能会ve域自动更新（例如：版本，状态等）。因此，您需要另一个类，例如：LocationData（它可以映射到表单，json等）和Location上的方法def update(data: LocationData): Location，它将应用更新。

来源

2015-11-13 11:39:21 LastRobotAlive

服务层应该将对象还是id作为输入？应该是对象吗？

回答

相关问题