Merge pull request #267 from bearsunday/update-roa

ROAのMVCとの違いを更新

manuals/1.0/en/15.tech.md

@@ -33,15 +33,17 @@ Access to resources is done using HTTP methods such as GET, POST, PUT, and DELET
 
 In BEAR.Sunday's Resource Oriented Architecture (ROA), each resource provides affordances (available operations and functions for the client) through hyperlinks. These links represent the operations that clients can perform and guide navigation within the application.
 
-#### Separation of Value and Representation
+#### Separation of State and Representation
 
-In BEAR.Sunday's ROA, the value of a resource is clearly separated from its representation. The value of a resource is managed by the application's domain logic, while the representation is for expressing that value in various formats (JSON, XML, HTML, etc.). This separation allows for loose coupling between domain logic and presentation logic.
+In BEAR.Sunday's ROA, the state of a resource and its representation are clearly separated. The state of the resource is managed by the resource class, and the renderer injected into the resource converts the state of the resource into a resource state representation in various formats (JSON, HTML, etc.). Domain logic and presentation logic are loosely coupled, and even with the same code, changing the binding of the state representation based on the context will also change the representation.
 
 #### Differences from MVC
 
-BEAR.Sunday's ROA takes a different approach from the conventional MVC (Model-View-Controller) architecture. While MVC composes an application with three components: model, view, and controller, BEAR.Sunday injects views into resource objects. Resources and views are loosely coupled, and their responsibilities are clearly separated.
+BEAR.Sunday's ROA (Resource Oriented Architecture) takes a different approach from the traditional MVC architecture. MVC composes an application with three components: model, view, and controller. The controller receives a request object, controls a series of processes, and returns a response. In contrast, a resource in BEAR.Sunday, following the Single Responsibility Principle (SRP), only specifies the state of the resource in the request method and is not involved in the representation.
 
-Also, in contrast to MVC where there are no constraints on the relationship between the controller and the model, resources have constraints on including other resources using hyperlinks and URIs, and this can be done declaratively.
+While there are no constraints on the relationship between controllers and models in MVC, resources have explicit constraints on including other resources using hyperlinks and URIs. This allows for declarative definition of content inclusion relationships and tree structures while maintaining information hiding of the called resources.
+
+MVC controllers manually retrieve values from the request object, while resources declaratively define the required variables as arguments to the request method. Therefore, input validation is also performed declaratively using JsonSchema, and the arguments and their constraints are documented.
 
 ### Dependency Injection (DI)
 
@@ -56,7 +58,7 @@ It also has the following characteristics:
 * Bindings can be changed by context, allowing different implementations to be injected during testing.
 * Attribute-based configuration enhances the self-descriptiveness of the code.
 * Ray.Di performs dependency resolution at compile-time, improving runtime performance. This is different from other DI containers that resolve dependencies at runtime.
-* Object dependencies can be visualized as a graph. Example: [Application Skeleton](/images/app.svg)
+* Object dependencies can be visualized as a graph. Example: [Root Object](/images/app.svg).
 
 <img src="https://ray-di.github.io/images/logo.svg" width="180" alt="Ray.Di logo">
 

manuals/1.0/ja/15.tech.md

@@ -33,15 +33,18 @@ URI（Uniform Resource Identifier）はWebの成功の鍵となる要素であ
 
 BEAR.Sunday のリソース指向アーキテクチャ (ROA) では、各リソースがハイパーリンクを通じてアフォーダンス（クライアントが利用可能な操作や機能）を提供します。これらのリンクは、クライアントが利用できる操作を表し、アプリケーション内をナビゲートする方法を指示します。
 
-#### 値と表現の分離
+#### 状態と表現の分離
 
-BEAR.SundayのROAでは、リソースの値と表現が明確に分離されています。リソースの値はアプリケーションのドメインロジックによって管理され、表現はその値を様々な形式（JSON, XML, HTMLなど）で表現するためのものです。この分離によってドメインロジックとプレゼンテーションロジックが疎結合になります。
+BEAR.SundayのROAでは、リソースの状態とそのリソース表現が明確に分離されています。リソースの状態はリソースクラスで管理され、リソースにインジェクトされたレンダラーが様々な形式（JSON, HTMLなど）でリソースの状態をリソース状態表現で変換します。ドメインロジックとプレゼンテーションロジックは疎結合で、同じコードでもコンテキストによって状態表現の束縛を変更すると表現も変わります。
 
 #### MVCとの相違点
 
-BEAR.SundayのROAは、従来のMVCアーキテクチャとは異なるアプローチをとっています。MVCはモデル、ビュー、コントローラーの3つのコンポーネントでアプリケーションを構成します。一方、BEAR.Sundayでは、リソースオブジェクトにビューがインジェクトされます。リソースとビューは疎結合で、それぞれの責務が明確に分離されています。
+BEAR.SundayのROA（リソース指向アーキテクチャ）は、従来のMVCアーキテクチャとは異なるアプローチを採用しています。
+MVCはモデル、ビュー、コントローラーの3つのコンポーネントでアプリケーションを構成し、コントローラーはリクエストオブジェクトを受け取り、一連の処理を制御してレスポンスを返します。一方、リソースはリクエストメソッドにおいて、単一責任原則（SRP）に従い、リソースの状態の指定のみを行い、表現には関与しません。
 
-また、MVCではコントローラーとモデルの関係に制約がないのと対照的に、リソースは他のリソースを含むことにハイパーリンクとURIを用いた制約があり、宣言的に行います。
+MVCではコントローラーとモデルの関係に制約はありませんが、リソースはハイパーリンクとURIを使用した他のリソースを含める明示的な制約があります。これにより、呼び出されるリソースの情報隠蔽を維持しながら、宣言的な方法でコンテンツの内包関係とツリー構造を定義できます。
+
+MVCのコントローラーはリクエストオブジェクトから手動で値を取得しますが、リソースは必要な変数をリクエストメソッドの引数として宣言的に定義します。そのため、入力バリデーションもJsonSchemaを使用して宣言的に実行され、引数とその制約がドキュメント化されます。
 
 ### 依存性の注入 (DI)
 
@@ -56,7 +59,7 @@ BEAR.SundayのDIは[Ray.Di](https://github.com/ray-di/Ray.Di)という独立し
 * コンテキストにより束縛を変え、テスト時に異なる実装を注入することができます。
 * アトリビュートによる設定でコードの自己記述性が高まります。
 * Ray.Diはコンパイル時に依存性の解決を行うため、ランタイム時のパフォーマンスが向上します。これは、ランタイム時に依存性を解決する他のDIコンテナとは異なる点です。
-* オブジェクトの依存関係をグラフで可視化できます。例）[アプリケーションスケルトン](/images/app.svg)
+* オブジェクトの依存関係をグラフで可視化できます。例）[ルートオブジェクト](/images/app.svg)
 
 <img src="https://ray-di.github.io/images/logo.svg" width="180" alt="Ray.Di logo">