1

私が最初に3層構造を教えられた方法は、次のとおりです。

  • dao
  • ドメイン
  • サービス
  • utils
  • jsf（beans）..。

インスタンス化可能な*erクラスは、これらのパッケージのいずれにも適合しません。特に、クラスが主に静的メソッドをグループ化するutilsには適合しません。それは副次的な考えとしてサービスに追加される可能性がありますが、それは厄介な感じがします。

それ以来、私はより精巧なパッケージ構造（おそらくMavenから借りたもの）を見てきました：

  • 定数（ハーコードされた定数と列挙型）
  • dao
  • dao.impl（インターフェースの実装）
  • モデル
  • リソース（プロパティファイルと構成ファイル用）
  • サービス
  • service.impl
  • ui..。

ただし、* erクラスを配置できる場所がまだわかりません。また、カスタム例外やSpringのこの元のパターンなど、他のタイプのクラスがポップアップ表示されるようになりました（以下を参照）。一般に、これらはフレームワーク/APIで一般的に見られるタイプのクラスのようです。

import org.springframework.context.ApplicationContext;

public class AppContext {  

    private static ApplicationContext ctx;  

    /** 
     * Injected from the class "ApplicationContextProvider" which is automatically 
     * loaded during Spring-Initialization. 
     */  
    public static void setApplicationContext(ApplicationContext applicationContext) {  
        ctx = applicationContext;  
    }  

    /** 
     * Get access to the Spring ApplicationContext from everywhere in your Application. 
     * 
     * @return 
     */  
    public static ApplicationContext getApplicationContext() {  
        return ctx;  
    }  
}

import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

public class ApplicationContextProvider implements ApplicationContextAware {  

    public void setApplicationContext(ApplicationContext ctx) throws BeansException {  
        // Wiring the ApplicationContext into a static method  
        AppContext.setApplicationContext(ctx);  
    }
}

これらまたはその他の「分類できない」ものをどのようにグループ化しますか？

4

1 に答える 1

1

これは、読み取り/書き込みクラスとEmailerクラスの機能によって異なります。

Emailerクラスが電子メールを送信すると仮定すると、インスタンス化可能なクラスであっても、アプリケーションロジックに厳密にバインドされていないため、 utilまたはhelperパッケージに収まります。

例外については、例外クラスを、それが使用されているパッケージのすぐ隣、または使用されているパッケージ内の別の*.exceptionsパッケージに配置するアプローチを見ました。

例えば：

application.dao
application.dao.impl
application.dao.exceptions
于 2011-06-28T10:19:04.413 に答える