From 95f241b3ec0da41d0f84eb865a04f6bbf7eef35a Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Mon, 22 Apr 2024 10:54:11 +0900 Subject: [PATCH 1/4] Update explanation of ROA in BEAR.Sunday manuals Made changes to clarify the difference between MVC and ROA architecture in BEAR.Sunday manuals. Expanded on and corrected the explanation of the request method, resource state, resource constraints, and input validation in ROA. These modifications have been applied to both the Japanese and English versions of the document. --- manuals/1.0/en/15.tech.md | 6 ++++-- manuals/1.0/ja/15.tech.md | 7 +++++-- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/manuals/1.0/en/15.tech.md b/manuals/1.0/en/15.tech.md index f097f364..d7ac251b 100644 --- a/manuals/1.0/en/15.tech.md +++ b/manuals/1.0/en/15.tech.md @@ -39,9 +39,11 @@ In BEAR.Sunday's ROA, the value of a resource is clearly separated from its repr #### 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) diff --git a/manuals/1.0/ja/15.tech.md b/manuals/1.0/ja/15.tech.md index e85356b5..4c89ded7 100644 --- a/manuals/1.0/ja/15.tech.md +++ b/manuals/1.0/ja/15.tech.md @@ -39,9 +39,12 @@ BEAR.SundayのROAでは、リソースの値と表現が明確に分離されて #### MVCとの相違点 -BEAR.SundayのROAは、従来のMVCアーキテクチャとは異なるアプローチをとっています。MVCはモデル、ビュー、コントローラーの3つのコンポーネントでアプリケーションを構成します。一方、BEAR.Sundayでは、リソースオブジェクトにビューがインジェクトされます。リソースとビューは疎結合で、それぞれの責務が明確に分離されています。 +BEAR.SundayのROA（リソース指向アーキテクチャ）は、従来のMVCアーキテクチャとは異なるアプローチを採用しています。 +MVCはモデル、ビュー、コントローラーの3つのコンポーネントでアプリケーションを構成し、コントローラーはリクエストオブジェクトを受け取り、一連の処理を制御してレスポンスを返します。一方、リソースはリクエストメソッドにおいて、単一責任原則（SRP）に従い、リソースの状態の指定のみを行い、表現には関与しません。 -また、MVCではコントローラーとモデルの関係に制約がないのと対照的に、リソースは他のリソースを含むことにハイパーリンクとURIを用いた制約があり、宣言的に行います。 +MVCではコントローラーとモデルの関係に制約はありませんが、リソースはハイパーリンクとURIを使用した他のリソースを含める明示的な制約があります。これにより、呼び出されるリソースの情報隠蔽を維持しながら、宣言的な方法でコンテンツの内包関係とツリー構造を定義できます。 + +MVCのコントローラーはリクエストオブジェクトから手動で値を取得しますが、リソースは必要な変数をリクエストメソッドの引数として宣言的に定義します。そのため、入力バリデーションもJsonSchemaを使用して宣言的に実行され、引数とその制約がドキュメント化されます。 ### 依存性の注入 (DI) From 4e7c2a2ae72502b6f9d9f335d15b3d3443f79ea4 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Mon, 22 Apr 2024 10:54:23 +0900 Subject: [PATCH 2/4] Refine terminology in BEAR.Sunday ROA documentation Updated the language used in the BEAR.Sunday documentation to better differentiate between MVC and ROA architectural approaches. Switched from the term "value" to "state" for more accurate depiction of the ROA, thus making it easier to understand the separation of state and representation within the resource. --- manuals/1.0/en/15.tech.md | 4 ++-- manuals/1.0/ja/15.tech.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/manuals/1.0/en/15.tech.md b/manuals/1.0/en/15.tech.md index d7ac251b..f7651913 100644 --- a/manuals/1.0/en/15.tech.md +++ b/manuals/1.0/en/15.tech.md @@ -33,9 +33,9 @@ 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 diff --git a/manuals/1.0/ja/15.tech.md b/manuals/1.0/ja/15.tech.md index 4c89ded7..8da68bc4 100644 --- a/manuals/1.0/ja/15.tech.md +++ b/manuals/1.0/ja/15.tech.md @@ -33,9 +33,9 @@ URI（Uniform Resource Identifier）はWebの成功の鍵となる要素であ BEAR.Sunday のリソース指向アーキテクチャ (ROA) では、各リソースがハイパーリンクを通じてアフォーダンス（クライアントが利用可能な操作や機能）を提供します。これらのリンクは、クライアントが利用できる操作を表し、アプリケーション内をナビゲートする方法を指示します。 -#### 値と表現の分離 +#### 状態と表現の分離 -BEAR.SundayのROAでは、リソースの値と表現が明確に分離されています。リソースの値はアプリケーションのドメインロジックによって管理され、表現はその値を様々な形式（JSON, XML, HTMLなど）で表現するためのものです。この分離によってドメインロジックとプレゼンテーションロジックが疎結合になります。 +BEAR.SundayのROAでは、リソースの状態とそのリソース表現が明確に分離されています。リソースの状態はリソースクラスで管理され、リソースにインジェクトされたレンダラーが様々な形式（JSON, HTMLなど）でリソースの状態をリソース状態表現で変換します。ドメインロジックとプレゼンテーションロジックは疎結合で、同じコードでもコンテキストによって状態表現の束縛を変更すると表現も変わります。 #### MVCとの相違点 From 751447fc6c874e8abf1149ebd187bd2404880b88 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Mon, 22 Apr 2024 10:57:25 +0900 Subject: [PATCH 3/4] Update object dependency example terminology The terminology in the object dependency example of both English and Japanese versions of the BEAR.Sunday documentation was changed. The reference term has been altered from "Application Skeleton" to "Root Object" to ensure accuracy and enhance comprehension. --- manuals/1.0/en/15.tech.md | 2 +- manuals/1.0/ja/15.tech.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/manuals/1.0/en/15.tech.md b/manuals/1.0/en/15.tech.md index f7651913..847b3e9e 100644 --- a/manuals/1.0/en/15.tech.md +++ b/manuals/1.0/en/15.tech.md @@ -58,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) Ray.Di logo diff --git a/manuals/1.0/ja/15.tech.md b/manuals/1.0/ja/15.tech.md index 8da68bc4..135fa29c 100644 --- a/manuals/1.0/ja/15.tech.md +++ b/manuals/1.0/ja/15.tech.md @@ -59,7 +59,7 @@ BEAR.SundayのDIは[Ray.Di](https://github.com/ray-di/Ray.Di)という独立し * コンテキストにより束縛を変え、テスト時に異なる実装を注入することができます。 * アトリビュートによる設定でコードの自己記述性が高まります。 * Ray.Diはコンパイル時に依存性の解決を行うため、ランタイム時のパフォーマンスが向上します。これは、ランタイム時に依存性を解決する他のDIコンテナとは異なる点です。 -* オブジェクトの依存関係をグラフで可視化できます。例）[アプリケーションスケルトン](/images/app.svg) +* オブジェクトの依存関係をグラフで可視化できます。例）[ルートオブジェクト](/images/app.svg) Ray.Di logo From 673f672ddb7808489fcd90ce1eaa07b708f57545 Mon Sep 17 00:00:00 2001 From: Akihito Koriyama Date: Mon, 22 Apr 2024 11:03:18 +0900 Subject: [PATCH 4/4] Update manuals/1.0/en/15.tech.md Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- manuals/1.0/en/15.tech.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manuals/1.0/en/15.tech.md b/manuals/1.0/en/15.tech.md index 847b3e9e..c37f4f83 100644 --- a/manuals/1.0/en/15.tech.md +++ b/manuals/1.0/en/15.tech.md @@ -58,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: [Root Object](/images/app.svg) +* Object dependencies can be visualized as a graph. Example: [Root Object](/images/app.svg). Ray.Di logo