私はOOを信じていますが、「OO準拠」のためだけに不適切な設計/実装を使用する必要があるほどではありません。
では、Servet/EJB/DataContainer レイヤード アーキテクチャを処理する方法は次のとおりです。
- サーブレットはリクエストを受け取り、「ビジネス レイヤー」を呼び出します (セッション EJB など)。
- ビジネス層は、データベースから DataContainers を見つけ、それらを操作してビジネス ロジックを実装します。
- DataContainers には実際のコードは含まれず、データベースに対応する get/set のみが含まれます。
このアプローチには魅力があります。DataContainers は何をするかが明確で、データがどこから来るかを非常に簡単に知ることができます。
オブジェクト指向ではないことは別として、これにより、名前を付けたり整理したりするのが難しい不明確なビジネス層クラスが発生します。
もっと「オブジェクト指向」になろうとしていたとしても(たとえば、これらのメソッドのいくつかを DataConatiners に入れるなど)、これらの操作のいくつかは複数のデータ セットに対して動作します。
DataContainers をビジネス ロジックで汚染することなく、ビジネス レイヤーが混乱を招くような手続き型にならないようにするにはどうすればよいでしょうか?
例
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 クラスにあまりにも多くのことを引き込み、ビジネス ロジックの再利用を困難にし、ユーザーを永続化戦略と結びつけるため、User にビジネス ロジックは必要ありません。
この例がそれほど悪くないことはわかっていますが、10 個の DataContainers と 20 個の BizLayer オブジェクトがそれぞれいくつかのメソッドを持っていると想像してください。これらの操作の一部が、特定のデータ コンテナーに「集中」していないことを想像してください。
これが手続き上の混乱にならないようにするにはどうすればよいでしょうか。