一般開発論
2571 ワード
詳細
ここではクライアント-サーバのみについて説明します.
一.一般階層
0:クライアント:クライアントは、web、android、iosなどです.クライアントは主にユーザーとのインタラクション、サーバ側とのインタラクションなどを担当します.
1:ルーティングレイヤ:主に配布リクエスト、パラメータチェック、呼び出しサービス、テンプレートレンダリングなどを担当します.
2:サービス層:主に領域モデルで構成され、具体的な要求サービスを実行する
3:最下位:データの永続化、サードパーティインタフェースへのアクセスなど、マシン操作を実行
サービス層
サービス層は主にレルムオブジェクトから構成され、レルムモデルの具体的な構造はリクエストのタイプに依存し、主に瞬時リクエストと非瞬時リクエストを含む.
瞬時要求:
瞬時要求は可能な限り無状態処理方法に変換される.すなわち、要求が完了すると、プログラムには状態保持がない.すべてのデータはパラメータにあり、最終的なステータスはデータベースとファイルシステムに保存されます.サービスなどは一連のsqlとio操作にマッピングされます.このようなサービスを設計するには、似たような機能を一緒に置くだけです.このような方法は基本的に継承上書きされないため,静的方法として設計できる.オブジェクト向けの方法はここではほとんど役に立たない.
レルムの最終モデルは、プログラムではなくデータベースにあります.このようなプログラムはデータベースとIOの操作方法にすぎない.そのため、データベース、ファイルシステムの設計とメンテナンスは最も核心的な部分です.
例:
ORMの選択:私はsqlをオブジェクトにマッピングするツールに傾いて、ORMはできるだけ簡単であるべきです.直接sqlを書くことが望ましいが、複雑なsqlは最適化する必要がある.
コードは、サードパーティのフレームワークを参照する必要がないなど、できるだけ簡単に維持する必要があります.
非瞬時要求:
オブジェクトがメモリに長く存在する場合にのみ、オブジェクト向けのメソッドを使用する必要があります.プログラムでモデリングしたり、さまざまなステータスを維持したり、さまざまなイベントを処理したりする必要があります.
例を挙げると、オンライン教室です.オンラインクラスサーバ側のプログラムモデルは、少なくとも授業中に長期にわたって存在しなければならない.教室の様々な状態は、教室の状態、使用するユーザーの接続、教室のリアルタイムデータなど、メモリに存在する必要があります.つまり、私のモデルは瞬時ではなく、長い間存在しています.
クラスモデルのライフサイクルを維持し、イベントの作成、初期化、処理、オブジェクトの破棄など
モジュールの区分:
モジュールの分割はルートオブジェクトを基準にする必要があります.ルートオブジェクトは、他のオブジェクトに依存せずに独立して存在します.レルムモデル設計では,ユーザを核心とすることはできず,レルム機能自体を核心とすべきであり,ユーザはユーザにすぎない.
ここではクライアント-サーバのみについて説明します.
一.一般階層
0:クライアント:クライアントは、web、android、iosなどです.クライアントは主にユーザーとのインタラクション、サーバ側とのインタラクションなどを担当します.
1:ルーティングレイヤ:主に配布リクエスト、パラメータチェック、呼び出しサービス、テンプレートレンダリングなどを担当します.
2:サービス層:主に領域モデルで構成され、具体的な要求サービスを実行する
3:最下位:データの永続化、サードパーティインタフェースへのアクセスなど、マシン操作を実行
サービス層
サービス層は主にレルムオブジェクトから構成され、レルムモデルの具体的な構造はリクエストのタイプに依存し、主に瞬時リクエストと非瞬時リクエストを含む.
瞬時要求:
瞬時要求は可能な限り無状態処理方法に変換される.すなわち、要求が完了すると、プログラムには状態保持がない.すべてのデータはパラメータにあり、最終的なステータスはデータベースとファイルシステムに保存されます.サービスなどは一連のsqlとio操作にマッピングされます.このようなサービスを設計するには、似たような機能を一緒に置くだけです.このような方法は基本的に継承上書きされないため,静的方法として設計できる.オブジェクト向けの方法はここではほとんど役に立たない.
レルムの最終モデルは、プログラムではなくデータベースにあります.このようなプログラムはデータベースとIOの操作方法にすぎない.そのため、データベース、ファイルシステムの設計とメンテナンスは最も核心的な部分です.
例:
public class UserService {
private static Logger log = LoggerFactory.getLogger(UserService.class);
public static User signin(SigninParam param) {
try(Connection con = MysqlPool.get()) {
User user = Sqlx.SelectOne(con , "select id,name,group from users where username=:username and password=:password" , param ,User.class);
return user;
} catch (SQLException e) {
log.error("UserService.signin sql error" ,e);
throw new CodeException(Codes.NO_SUCH_USER);
}
}
}
public class SigninParam {
public String username;
public String password;
}
ORMの選択:私はsqlをオブジェクトにマッピングするツールに傾いて、ORMはできるだけ簡単であるべきです.直接sqlを書くことが望ましいが、複雑なsqlは最適化する必要がある.
コードは、サードパーティのフレームワークを参照する必要がないなど、できるだけ簡単に維持する必要があります.
非瞬時要求:
オブジェクトがメモリに長く存在する場合にのみ、オブジェクト向けのメソッドを使用する必要があります.プログラムでモデリングしたり、さまざまなステータスを維持したり、さまざまなイベントを処理したりする必要があります.
例を挙げると、オンライン教室です.オンラインクラスサーバ側のプログラムモデルは、少なくとも授業中に長期にわたって存在しなければならない.教室の様々な状態は、教室の状態、使用するユーザーの接続、教室のリアルタイムデータなど、メモリに存在する必要があります.つまり、私のモデルは瞬時ではなく、長い間存在しています.
クラスモデルのライフサイクルを維持し、イベントの作成、初期化、処理、オブジェクトの破棄など
public class Course extends Room{
private List clients;
private Client teacher;
private int courseId;
public Course(int courseId) {
this.courseId= courseId;
}
@Override
public void handleMessage(Message message) {
switch (message.cmd) {
case start:
break;
default:
break;
}
}
public void close(){
}
}
モジュールの区分:
モジュールの分割はルートオブジェクトを基準にする必要があります.ルートオブジェクトは、他のオブジェクトに依存せずに独立して存在します.レルムモデル設計では,ユーザを核心とすることはできず,レルム機能自体を核心とすべきであり,ユーザはユーザにすぎない.