メインコンテンツまでスキップ

アーキテクチャ概要

自動生成と手動実装の分離​

自動生成されるコードは __AutoGenerated などといった名称のフォルダの中に生成されます。これらと開発者 が手動で実装するコードとは、明確にファイルやフォルダが分離されています。 スキーマ定義を変更してコードを再生成しても、手動実装されたビジネスロジックやUIコンポーネントが上書きされて消えることはありません。

以下は Nijo を用いた典型的なプロジェクトのソースコード構成例です。オレンジ色の部分がソースコード生成のたびに毎回洗い替えられます。手動実装コードはオレンジ色の部分の外に置くことで、再生成しても消えないようになっています。

自動生成コードと手動実装コードの分離イメージ図

レイヤー構成​

Nijoが生成する標準テンプレートは、一般的な3層アーキテクチャを採用しています。 各レイヤーの責務と、自動生成コードと手動実装コードがどのように分離・統合されているかを解説します。

まず全体像を図で示します。

Nijo の標準アーキテクチャ図

黄色が自動生成される領域、赤色が開発者が手動で実装する領域です。レイヤーごとに責務を分けつつ、再生成しても手動実装側が上書きされない構成になっています。

1. プレゼンテーション層 (Web / UI)​

  • プロジェクト: MyApp.Web.csproj (ASP.NET Core), client/ (React + TypeScript)
  • 役割: ユーザーインターフェースの提供とHTTPリクエストの処理。
  • 構成:
    • フロントエンド: JavaScript。NijoはAPIクライアントと型定義のみを生成し、UIの実装は開発者に委ねられます。バックエンドとのHTTPリクエストではJSONでのやり取りを行います。
      • 自動生成: Web バックエンド側で自動生成されたコントローラーと完全に同期されたエンドポイント定義、およびリクエスト/レスポンスの型定義（TypeScript）。
      • 手動実装: UIライブラリやCSSフレームワークの選定、画面構築は完全に自由です。採用必須なのはTypeScriptのみです。
    • バックエンド: ASP.NET Core Controller。Nijoは基本的なCRUD操作を行うControllerを自動生成します。処理内容としては、ビジネスロジック層を薄くラッピングする程度を基本とします。具体的には、HTTPリクエスト/レスポンスをC#のオブジェクトと変換する程度がここでの仕事です。
      • 自動生成: モデルごとのコントローラーとアクション。
      • 手動実装: Webサーバーとしての基本的な挙動（HTTP/HTTPS設定、Cookie/OAuth認証など）は、通常の ASP.NET Core アプリケーションと同様に Program.cs 等で自由に実装します。.AddControllers() により、自動生成されたコントローラーも自動的にスキャンされ統合されます。

2. ビジネスロジック層 (Core)​

  • プロジェクト: MyApp.Core.csproj
  • 役割: 業務ルールの実装、データの加工、トランザクション管理。
  • 構成:
    • Application Service: プレゼンテーション層からの要求を受け、データアクセス層を使って業務処理を実行します。データの登録・更新・削除・検索、その他複雑な処理は基本的にすべてここに実装されます。このクラスのライフサイクルはエンドユーザーやスケジューラからのリクエスト1回分です。つまりWebであればHTTPリクエスト1個分。もしスケジューラによるバッチ実行があるアプリであれば、当該実行1回分です。したがって、このサービスクラスは状態を持ってはいけません。
  • 自動生成と手動実装の分離方法: 「ジェネレーションギャップパターン」を採用しています。中心となるサービスクラスは abstract class として自動生成されます。開発者はこれを継承した具象クラスを作成し、メソッドをオーバーライドすることで振る舞いを拡張します。

3. データアクセス層 (Infrastructure)​

  • プロジェクト: MyApp.Core.csproj (ビジネスロジック層と同居)
  • 役割: データベースとのやり取り。
  • 構成:
    • Entity Framework Core: O/Rマッパーとして機能し、データベース操作を抽象化します。
  • 自動生成と手動実装の分離方法
    • 自動生成: スキーマ定義に基づいた DbContext 、 Fluent API によるモデル定義処理 OnModelCreating 、エンティティクラスが生成されます。
    • 手動実装: 自動生成される OnModelCreating のあとに、任意の OnModelCreating 処理を追加できます。

登録更新画面のランタイム遷移​

レイヤー図だけでは、実際にどのオブジェクトがリクエストごとに生成され、どこで値が詰め替えられるかが見えにくいため、登録更新画面の実行時の流れも図にします。以下はデモ101の「売上詳細」画面を題材に、画面初期表示から更新確定後の画面再読込までを追ったものです。

この図で重要なのは、初期表示も保存も CommandModel のエンドポイントとして扱われる点と、サーバー側では IPresentationContext に ReturnValue や Messages を詰めて返す点です。クライアント側はその戻り値として DisplayData を受け取り、保存成功後は navigate または revalidate により同じ初期表示フローをもう一度通して最新状態を読み直します。

画面初期表示処理のシーケンス図の例​

登録更新画面のランタイムにおけるオブジェクト遷移の主体別シーケンス図

保存処理のシーケンス図の例​

登録更新画面のランタイムにおけるオブジェクト遷移の主体別シーケンス図

Web以外のUIフレームワークへの流用​

Nijoが生成するビジネスロジック層（MyApp.Core）は、特定のUIフレームワークに依存しない純粋な .NET クラスライブラリです。 デモでは ASP.NET Core と React を採用していますが、これら2つのソースを利用せず、 MyApp.Core を直接参照することで、Windows Forms や WPF、コンソールアプリケーション など、全く異なるプラットフォームのアプリケーションを構築することも可能です。 その場合、UI部分は手動で実装する必要がありますが、堅牢なデータモデルとビジネスロジックはそのまま再利用できます。