我相信 OO,但不至于应该使用不适当的设计/实现来实现“OO 兼容”。
那么,如何应对 Serlvet/EJB/DataContainer 分层架构:
- Servlet 接收请求并调用“业务层”(例如会话 EJB)
- 业务层从数据库中定位DataContainers并对其进行操作以实现业务逻辑
- DataContainers 不包含真正的代码,只是获取/设置对应于数据库。
这种方法很有吸引力;DataContainers 清楚地知道它们的作用,并且很容易知道数据的来源。
除了不是 OO 之外,这还会导致业务层类不清楚,难以命名和组织。
即使我们试图更加“OO”(例如,将其中一些方法放在 DataConatiners 中),其中一些操作对不止一组数据进行操作。
您如何防止业务层变得混乱,但又不会用业务逻辑污染您的 DataContainer?
例子
class UserServlet {
handleRequest() {
String id = request.get("id");
String name = request.get("name");
if (UserBizLayer.updateUserName(id,name))
response.setStatus(OK);
else
response.setStatus(BAD_REQUEST);
}
}
class UseBizLayer {
updateUserName(String id, String name) {
long key = toLong(id);
user = userDAO.find(key);
if user == null
return false;
if (!validateUserName(name))
return false;
user.setName(name);
userDAO.update(user);
return true;
}
validateUserName(String name) {
// do some validations and return
}
}
class User {
long key;
String name;
String email;
// imagine getters/setters here
}
- 我们不想要
validateUserName
用户,因为它只对名称进行操作;我想它可以进入另一个类,但是我们有另一个程序“uti”类型类 - 我们不希望在 User 上使用持久化方法,因为将数据结构与其持久化策略解耦是有价值的
- 我们不希望 Servlet 中包含业务逻辑,因为我们可能需要在其他地方重用该逻辑
- 我们不希望我们的业务逻辑在我们的用户中,因为这对用户类有太多的吸引力,使得业务逻辑的重用变得困难,并将用户与其持久性策略相耦合
我意识到这个例子并没有那么糟糕,但是想象一下 10 个 DataContainers 和 20 个 BizLayer 对象,每个对象都有几个方法。想象一下,其中一些操作并非“以”特定数据容器为中心。
我们如何防止这成为程序上的混乱?