1

いくつかのJavaEEプロジェクトを読んだとき、これらのプロジェクトの構造、フレームワークは複雑で、おそらく不要であることがわかりました。

ユーザーコントローラー1ファイル

UserService、UserServiceImpl2ファイル

UserDao、UserDaoImpl2ファイル

私の仕事は単純で、CRUDだけです。何かを変更するときは、4つのファイルを除いて編集する必要がありますが、効率が悪いのではないでしょうか。これらのレイヤー設定はパフォーマンスの効果を変更しますか？

Usercontroller-UserService extends BaseService-BaseDaoは、これらをよりシンプルで効果的、またはより生産的にしますか？</ p>

あなたが2つの仕事をしているなら、インターネットウェブプロジェクトと企業のミス

レイヤー構造についてどう思いますか？

4

2 に答える 2

3

コントローラーでデータベースに直接クエリを実行することを妨げるものは何もありません。しかしある日、あなたは次のことに気付きます。

  • ビジネス ロジックを Web サービスと共有したいと考えています。突然、すべてのビジネス ロジックがコントローラー内にあることに気付きます。それを個別のクラス (サービス層と呼ばれる) に抽出し、そのコードをコントローラーと Web サービスの両方から再利用する必要があります。

  • 先日、誰かがからに切り替えることにしました。突然、ネイティブ データベースの SQL クエリが至る所で見つかります (コントローラーではなく、サービス内)。保守性のために、データベースに関連するすべてのコードを別のクラス (永続層またはDAO 層と呼ばれる)に移動することにします。

  • もう一度 Oracle データベースに移行した後、今度はに切り替えるように求められました。ただし、既存のものを書き換える代わりに、UserDaoそれをインターフェイスに変更し、元の実装をそのままにしOracleUserDaoて、という 2 番目の実装を作成します。MongoDbUserDao

  • 単体テスト中に、サービス クラスのモックは面倒であることがわかりました。また、クラス内にビジネスメソッドが見えにくいため、明確な API でサービス インターフェイスを抽出します。

3 層アーキテクチャに従うことを強制する人は誰もいないと思いますが、それは開発中に自然に現れます。それを待つか、初日から if から始めることができます。

于 2012-04-08T10:40:33.253 に答える
0

レイヤーの実装を緊密に結合しているインターフェースを取り出すと、何かをモックしてそのモックをテストで使用したい場合に問題が発生します。あなたはテストスイートを持っていますね？

それとは別に、プログラミングとインターフェースを使用すると、いつでも実装を変更できます。したがって、他のレイヤーからコードを変更することなく、たとえば、ローカルではなくリモートサービスレイヤーに接続できます。

于 2012-04-08T01:49:21.040 に答える