1

クラス階層がどのようにあるべきかについてのいくつかのガイドを読んだ後、私は階層化アーキテクチャにかなり慣れていません+春+休止状態-

私はこの構造を思いつきました：

public interface GenericDAO {

   public <T> T getItemById(long id, Class<T> c);

   public <T> int save(T... objectsToSave);

   public <T> int saveOrUpdate(T... objectsToSave);

   public <T> int delete(T... objectsToDelete);
       .
       .
}

現在、他のすべての daos impl は、基本的なメソッドを使用するために、このジェネリック dao をプライベート フィールドとして使用しています。

@Repository
public class UserDAOImpl implements UserDao {

      @Autowired
      private GenericDAO dao;

      @Override
      public int deleteUser(User u) {
        return dao.delete(u);

      }

      .
      .
      .
}

私のサービスは次のようなものです：

 @Service
 public class UserServiceImpl implements UserService {

     @Autowired
     private UserDao userDao;


     @Transactional(readOnly = false)
     public int deleteUser(User u) {
         return userDao.deleteUser(u);
     }
         .
         .
         .
 }

プロジェクトで UserDaoImpl 、 CarDaoImpl 、 XDaoImpl が必要な理由がわかりません。すべての XDaoImpls が同じに見えるため、非常に冗長に見えます。

 @Repository
 public class UserDAOImpl implements UserDao {

      @Autowired
      private GenericDAO dao;

      @Override
      public int deleteUser(User u) {
        return dao.delete(u);

      }

      .
      .
      .
}

@Repository
public class CarDAOImpl implements CarDao {

      @Autowired
      private GenericDAO dao;

      @Override
      public int deleteCar(Car c) {
        return dao.delete(c);

      }

      .
      .
      .
}

@Repository
public class XDAOImpl implements XDao {

      @Autowired
      private GenericDAO dao;

      @Override
      public int deleteX(X c) {
        return dao.delete(c);

      }

      .
      .
      .
}

XDaoImpl を作成できず、代わりに GenericDaoImpl を使用して、多くのクラス作成を節約できましたか?

deleteUserCar(User u) のような複雑なアクションが必要な場合は、サービスにロジックを実装するだけです。

UserService {
          public void deleteUserCar(User u) {
             Car c = u.getCar();
             CarService cs.deleteCar(c);

          }  
}

何か不足していますか？XDaoImpl の代わりに GenericDaoImpl のみを使用すると後悔する例を教えてください。

ありがとう

4

2 に答える 2

1

  • サービスは後で DAO にメソッドを渡すだけでなく、ビジネスロジックを呼び出します。値を検証し (例: 存在するか、一意であると想定されているか)、計算を実行します (例: int getStock() { return bought - sold; }.

  • 一般的な DAO は優れていますが、 のabstract class代わりに を検討してinterfaceください。この方法では、複数の を作成する必要はなくcreate()、抽象的な DAO を拡張するだけです (例: CarDAO extends AbstractDAO<Car>)。

  • 拡張 DAO は、classit ハンドルを一般的な抽象 DAO に渡します (前の例で見たように)。

  • 拡張された DAO は後で、その特定のオブジェクトにのみ適用される追加のメソッドを実装しますList<Car> getCarsWithColor(Color color)。

  • Service -> DAO の関係は常に 1 対 1 であるとは限りません。次の DAO を考えてみましょう: TruckDAO、CarDAO、VanDAOオブジェクトTruck extends Vehicle、Car extends Vehicle、Van extends Vehicle。3 つのサービスが必要ですか、それとも(おそらくVehicleServiceすべての に対してロジックを実行します) カバーしますか?Vehicle

  • インターフェイスの使用を再考してください。この質問はに適用されますC#が、概念は同じです。

于 2013-05-16T07:30:28.180 に答える