Action-Domain-Responder-Webタスク用のMVCの最終処理

目的

WebクライアントとWebアプリケーション間のユーザーインターフェイスの対話を、明確に定義された3つの役割に分割します。

背景

MVCという用語は、特にWebのコンテキストで、元の意味のセマンティックぼかしが発生します（この問題の詳細については、 Stefan Pribshのビデオを参照してください）。 この不鮮明さを解消する手段として、Web固有のタスクを解決するためのMVCコンセプトの改良版であるAction-Domain-Responderパターンの説明に注目します。



ADRは、日々のWeb開発プロセスで実際に実装するものに沿って、はるかに優れていると思います。 たとえば、このパターンの作成は、ルーティングとスケジューリングの問題を解決する方法に部分的に触発されました。これは、一般的な場合、ルーティングとスケジューリングの際に、コントローラークラス自体ではなく 、このコントローラークラスの特定のアクションメソッドを参照しているためです。



もう1つの問題は、 Viewをテンプレートとしてよく見ているという事実です。ただし、Webのコンテキストでは、 ViewはHTTP応答であると言う方がおそらく適切でしょう。 前述に基づいて、ADRはMVCよりもWebアプリケーションの概念をより適切に分離できると考えています。

コンポーネント

アクションは、 ドメインとレスポンダーを接続するロジックです。 入力データを使用してDomainとやり取りし、 Domainの出力をRespondentに渡します。



ドメインには、セッション、アプリケーションおよび環境データを管理し、状態を変更し、必要に応じてデータを管理するためのロジックが含まれています。



レスポンダーは、HTTP応答または応答の説明を作成するために必要なロジックです。 基本コンテンツ（本文コンテンツ）、テンプレートとプレゼンテーション、ヘッダー、Cookie、ステータスコードなどで動作します。

相互作用

1. Webハンドラーはクライアントからリクエストを受け取り、それをActionに渡します。
2. アクションはDomainと相互作用します。
3. このアクションは、データを回答者に転送します（このデータには、 ドメインとのやり取りの結果、クライアント要求からのデータなどが含まれる場合があります）
4. レスポンダーは、 Actionから受信したデータを使用して応答を生成します。
5. Webハンドラーは、クライアントに応答を送信します。

MVC（Model-View-Controller）との比較

Web内の相互作用を記述する最も一般的なパターンはModel-View-Controllerです。 Action-Domain-Responderは本当に偽装されたModel-View-Controllerですか？ ADR要素がMVC要素に非常に明確に反映されていることに気付くかもしれません。

Model <--> Domain View <--> Responder Controller <--> Action
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2つのパターンは非常によく似ています。 違いは何ですか？



一般に、ファウラーのエッセイ「 GUIアーキテクチャ 」[翻訳]から、「複数のビューと1つのコントローラーがあり、ページ上の各ブロック、各コントロール、ページ全体として。」 これは、WebアプリケーションでMVCを適用するときに発生するセマンティックブラーの主要な要素です。



そして、MVCとADRの個々のコンポーネントをさらに詳しく比較しましょう。

モデルとドメイン

ADRでは、 Responderがドメインと重要な方法で相互作用しないことを除いて、それらに根本的な違いはありません。 レスポンダーは、 ドメインオブジェクトをエンティティおよびコレクションとして使用できますが、表示目的のみです。 レスポンダーは、MVCのフレームワークで規定されているように、 ドメインを変更せず、情報を送信しません。

コントローラーとアクション

一般的な場合、MVCの原則に従って設計されたシステムのコントローラーのほとんどのクラスには、特定のアクションに対応するメソッドがいくつか含まれています。 これらのすべてのメソッドは1つのControllerに存在するため、これらの各メソッドで動作する追加の「ラッピング」ロジックも追加されます（たとえば、アクション自体の直前または直後に起動するフック）。 このルールの重要な例外はマイクロフレームであり、各コントローラーは個別のクロージャーまたは呼び出されるオブジェクトであり、 アクション （例： Slim ）とより一貫しています。



ADRのフレームワーク内では、 アクションは個別のクラスまたはクロージャーと見なされます。 つまり、各アクションは、独自の個別のクラスまたはクロージャーに配置する必要があります。



このアクションは、 コントローラーがモデルとやり取りするのと同じ原則に従ってドメインとやり取りしますが、 ビューまたはテンプレートシステムとはやり取りしません。 アクションは、単にデータを応答者に送信し、それを個別に破棄するために提供します。

表現と回答者

MVCシステムでは、通常、 Controllerメソッドはビューを使用して（たとえば、 テンプレートビューまたは2ステップビューを使用して）応答本文を生成します 。 次に、 コントローラーは、生成された応答本体を応答自体に統合します。 アクションであるControllerメソッドは、応答を直接制御して必要なヘッダーを設定します。



コントローラーの一部のメソッドは、同じデータに対して異なる応答形式を提供できる場合があります。 ほとんどの場合、この変動は絶対にすべてのメソッドでサポートされていないため、データ表示のロジックはメソッドごとに何らかの方法で変化し、それぞれの場合に独自の条件があります。



ADRでは、各アクションに対応するResponderがあります。 アクションは、 ドメインとの対話を完了すると、必要なすべてのデータとこのデータの制御の両方をドメインから 回答者に転送します。 レスポンダーは、ヘッダーの設定、コンテンツタイプの選択、テンプレートのレンダリングなどを完全に制御します。



Responderには、 テンプレートエンジン 、 ツーステップテンプレートエンジン 、 トランスフォームビュー、またはその他のプレゼンテーションシステムが含まれることがあります。 また、一般的なResponderは複数のActionで使用できることに注意してください。 主なことは、 アクションがヘッダーとコンテンツに関するすべての作業をRespondentに委ねることであり、個々のSubmissionに対して独自のResponderを作成するために必要なことではありません。

他のパターンとの比較

MVCコンセプトを改良、置換、または補完するものと見なされる他のパターンがあります。 Derek Greerによるパターンのこのレビューを確認できます 。

EBI（エンティティ境界インタラクター）

EBI用語には、ポートとアダプター、六角形アーキテクチャ、 ECB （Entity-Control-Boundary）という同義語がいくつかあります。 Robert MartinのClean Architectureの一部として説明されています。



EBIはMVCの部分的な代替手段であり、 InteractorおよびEntityオブジェクトによって表される基本的な要素と動作が、 Boundaryを使用して着信データと発信データから分離されます。 このアプローチの主な結果は、アプリケーション自体と入力および出力メカニズムの複雑さとの明確な区別です。そのため、キーの動作は、要求の受信または応答の送信について特定のシステムに依存しません。



私は認めます、私はEBIの概念にあまり精通していないので、この説明は一般的または特定的に完全に正しいとは限りません。 この分野での不完全な研究の後、EBIアーキテクチャはおそらくMVCよりもアプリケーション内の相互作用を説明しているという結論に達しました。 上記の説明が正しい場合、ADRはEBI構造にかなり適合しています。

• ADRのアクションとレスポンダーはWeb固有のリミッターとして機能します
• ADR ドメインは、ADR アクションからEBI エンティティの要素をカプセル化または非表示にするInteractorの類似体として機能できます。

あるいは、ポートおよびアダプターの用語または六角形のアーキテクチャーの観点から、 アクションを「ポート」と見なす方が合理的である場合があります。これは、ABI ドメインの一部としてEBI Invokeが呼び出されるポートです。 最後に、 レスポンダーは、アプリケーションがデータをクライアントに返す「アダプター」と考えることができます。



ただし、ADRはEBIを直接置き換えるものではないようです。 むしろ、2つのアプローチは互いに補完します。

DCI（データコンテキスト相互作用）

DCIはMVCへの追加として説明されており 、代替ではありません。 同程度にADRサプリメントと呼ぶのは公平だと思います。

MVP（モデルビュープレゼンター）

MVPは、 Supervising ControllerおよびPassive Viewパターンによって廃止されました 。 一見すると、特にパッシブビューとモデルが相互に依存関係がないという点で、ADRと非常によく似ています。 ファウラーのテキストから：

コントロールコントローラーは、コントローラーを使用して入力データを処理し、プレゼンテーションを制御します。これにより、より複雑な表示ロジックを整理できます。



パッシブビューは、ユーザーイベントへの応答を処理するだけでなく、ビューを更新するすべての作業を行うコントローラーを使用して、UI要素の動作数を最小限に抑えることでこれを実現します。 このアプローチにより、ビューの問題を心配することなく、コントローラーのテストに集中できます。

もう少し詳しく見てみましょう。

• モデルとドメインは 、MVCの場合と同様、ほとんど同じです。
• 受動的見解は、 行動も回答者とも完全に一致していません。 むしろ、クライアントに返される応答として見ることができます。
• 管理コントローラーは、「ビューを管理してより複雑な表示ロジックを実現する」という点でレスポンダーに似ています。 一方、 レスポンダーはドメインと相互作用せず、クライアントからの入力を受信しないため、 管理コントローラーの役割に適していないようです。
• または、 コントロールコントローラーを Actionとして表すこともできますが、 アクションはビュー（つまり、応答）の管理を担当しません。

一般的に、近いですが、同じではありません。

MVVM（Model-View-ViewModel）

MVVMはADRと部分的にのみ類似しています。 MVVMのモデルは、MVCのモデルおよびADRのドメインとほぼ同じです。 同様に、MVVMでの表示は、MVCでの表示およびADRでのレスポンダーに非常に似ています 。



ただし、 ViewModelはMVCのコントローラーにもADRのアクションにも似ていません。 ADRはMVCの改良版であるため、MVVMとMVCを比較することはADRと比較することに似ていると想定するのが合理的です。



これらの違いの詳細については、 Joel Wenzel 、 Avtar Singh Soha 、 Rachel Appel 、 Niraja Bhattaの記事を読むことをお勧めします。



（興味深いメールのディスカッションがありましたが、その間にMVVMはMVCに非常に似ており、 ビューとモデルの間の相互作用のためにビューモデルを追加したと説明しました。これが本当にそうなら、 ビューモデルをADRで使用してMVCと同じ成功）。

PAC（プレゼンテーション-抽象化-コントロール）

ウィキペディアから ：

PACはエージェントの階層構造であり、各エージェントは表現、抽象化、および制御の3つの部分です。 エージェント（トライアド）は、それぞれの制御部分を介してのみ互いに​​通信します。 MVCとのもう1つの違いは、各トライアドで、表現と抽象化（MVCに関するモデル）が完全に分離されていることです。 このアプローチにより、異なるスレッドでモデルとビューを並行して処理することができ、抽象化が完全に初期化される前でもインターフェース（ビュー）を表示できるため、非常に迅速な開始の印象をユーザーに残します。

ADRとあまり似ていません。

RMR（リソースメソッド表現）

ircmaxellがRedditを指すまで、私はRMRについて聞いていませんでした。



ADRとRMRは互いに非常に似ており、それらの要素は互いに非常に正確に対応しています。

 Resource <--> Domain Method <--> Action Representation <--> Responder
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、RMRのニュアンスのいくつかは、これら2つのアプローチがまだ互いに異なると信じさせています。 例：

したがって、オブジェクト指向言語のフレームワーク内で、httpリソース（リソース）はプライベートプロパティと、それぞれが標準HTTPメソッドに対応する特定のパブリックメソッドのセット（メソッド）を持つオブジェクトと見なすことができます。 MVCに関しては、リソースは内部にコントローラーの小さな部分を持つモデルとして表すことができます。

個人的には、コンセプトが混ざりすぎているように思えます。 アプリケーションで実行されるアクションからモデルをより明確に分離することを好みます。

表現は、MVCの表現と非常によく似ています。リソースオブジェクトを指定し、必要な出力形式にシリアル化するコマンドを指定します。

明らかに、これは、たとえば「見つかりません」など、多くのHTTP応答には当てはまりません。 このような答えは、要求されたリソースの表現ではありません。



一般に、ADRはRMRの拡張および拡張されたバリエーションと見なされる可能性が高く、ADRで実行できるリソースとアクションはDomainsとActionsに明確に分割され、 ビュー （つまり、応答の生成）が制御されます被告 。

モデル-操作-ビュー-イベント（MOVE）

元のサイトから：

モデルは、アプリケーションが知っているすべてをカプセル化します。

オペレーションは、アプリケーションが行うすべてをカプセル化します。

ビューは、アプリケーションとユーザーの間のリンクです。

イベントは、これらすべての要素を安全に接続するために使用されます。

これはそれ自体非常に興味深いパターンです。 モデルと操作の概念は、「ドメイン駆動設計」アプローチのフレームワークで非常に適切であると思われます。



ただし、特にこの時点では、MOVEはADRのようなものではないと思います。

イベントは、MOVE（およびMVC）が制御の反転を提供するものです。これは、モデルが更新中のビューに関する情報を受信せずにビューを更新できるようにするために必要です。

ADRでは、 ドメインとレスポンダーは「相互に更新」しません。 ドメインの作業が完了し、結果が被告に転送されて、クライアントにさらに表示されます。

分離プレゼンテーション

別のビューで 、ADR、特にResponderへの参照をいくつか見つけることができます。 記事自体は読む価値がありますが、個別のビューは、この分離を実現する具体的な方法ではなく、プレゼンテーションからデータを分離する一般的なアプローチを説明するメタパターンである可能性が高くなります。

例でのMVCとADRの比較

MVCの開始点

MVCでは、一般的なブログシステムのディレクトリ構造は次のようになります。 インデックスと読み取りは代替としてJSON出力を提供し、コメントテンプレートは「部分的」であり、代替としてJSON出力も許可することに注意してください。

 controllers/ BlogController.php # index(), create(), read(), update(), delete() models/ BlogModel.php views/ blog/ index.html.php index.json.php create.html.php read.html.php read.json.php update.html.php delete.html.php _comments.html.php _comments.json.php
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、MVCの別のタイプのディレクトリ構造は次のとおりです。

 Blog/ BlogController.php # index(), create(), read(), update(), delete() BlogModel.php views/ index.html.php index.json.php create.html.php read.html.php read.json.php update.html.php delete.html.php _comments.html.php _comments.json.php
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MVCの標準コントローラークラスは、およそ次のとおりです。 Controllerのこのクラスにはさまざまなアクションがあり、これらのアクションのメソッドが応答ヘッダーを設定することに注意してください。

 <?php use Framework\Controller; class BlogController extends Controller { public function create() { // is this a POST request? if ($this->request->isPost()) { // retain incoming data $data = $this->request->getPost('blog'); // create a blog post instance $blog = $this->blog_model->newInstance($data); // is the new instance valid? if ($blog->isValid()) { // yes, save and redirect to editing $blog->save(); $this->response->redirect('/blog/edit/{$blog->id}'); return; } else { // no, show the "create" form with the blog instance $this->response->setContent($this->view->render( 'create.html.php', array('blog' => $blog), )); return; } } else { // not a POST request, show the "create" form with defaults $this->response->setContent($this->view->render( 'create.html.php', array('blog' => $this->blog_model->getDefault()) )); } } public function index() { // ... } public function read($id) { // ... } public function update($id) { // ... } public function delete($id) { // ... } } ?>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

create（）メソッドのロジックは、モデルとのやり取りのほとんどをサービスレイヤーに移すことで何らかの方法で削減できますが、本質は同じままです。通常、応答ヘッダーとコンテンツを担当するのはコントローラーです 。

ADRをご覧ください

比較のために、ADRを使用したフォルダー構造は次のように編成できます。 各アクションには、それに対応する回答者がいることに注意してください。

 Blog/ Action/ BlogIndexAction.php BlogCreateAction.php BlogReadAction.php BlogUpdateAction.php BlogDeleteAction.php Domain/ # Model, Gateway, Mapper, Entity, Collection, Service, etc. Responder/ BlogIndexResponder.php BlogCreateResponder.php BlogReadResponder.php BlogUpdateResponder.php BlogDeleteResponder.php html/ index.html.php create.html.php read.html.php update.html.php delete.html.php _comments.html.php json/ index.json.php read.json.php _comments.json.php
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のcreate（） Controllerメソッドに対応するActionとResponderのペアは次のようになります。

 <?php use Framework\Action; class BlogCreateAction extends Action { public function __invoke() { // is this a POST request? if ($this->request->isPost()) { // yes, retain incoming data $data = $this->request->getPost('blog'); // create a blog post instance $blog = $this->blog_model->newInstance($data); // is the new instance valid? if ($blog->isValid()) { $blog->save(); } } else { // not a POST request, use default values $blog = $this->blog_model->getDefault(); } // set data into the response $this->responder->setData(array('blog' => $blog)); $this->responder->__invoke(); } } ?>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 <?php use Framework\Responder; class BlogCreateResponder extends Responder { // $this->response is the actual response object, or a response descriptor // $this->view is a view or template system public function __invoke() { // is there an ID on the blog instance? if ($this->data->blog->id) { // yes, which means it was saved already. // redirect to editing. $this->response->setRedirect('/blog/edit/{$blog->id}'); } else { // no, which means it has not been saved yet. // show the creation form with the current response data. $this->response->setContent($this->view->render( 'create.html.php', $this->data )); } } } ?>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

繰り返しますが、このコードでは、特にDomainでの作業に関して、リファクタリングの機会を見つけることができます。 主なことは、 アクションが被告の仕事を何もしないということです。 必要なすべての作業は、 回答者のロジックによって直接実行されます。



ADRコードの拡張例については、 こちらをご覧ください 。

コメント

リクエストとはみなされません

「HTTPリクエスト」に対応する要素をパターンに含めなかったため、非常に多くの批判を受けました。 この出版物の以前のバージョンにはそのような要素が含まれており、「Request-Action-Domain-Response」と呼ばれていました。 ただし、MVCおよび同様のアーキテクチャパターンをさらに検討すると、入力要素を定義するものがないことに気付きました。 一般的な行から抜け出さないために、ADRはこの要素も考慮しません。

フロントコントローラーなし

このパターンは、一般的なWebアプリケーションではなく、 Model-Application-Controllerアプローチを改善するために作成されました。 したがって、多くのWebアプリケーションに固有の要素には意図的に対応していません。特に、これはFront Controllerに当てはまります 。



ADRは、ルーティングまたはスケジューリング要素については説明しません。また、 アクションとレスポンダーがスケジューリングにどのように関連付けられるかについても説明しません。 ほとんどの場合、ルーティングとスケジューリングはフロントコントローラーの責任であり、 アクション 、 レスポンダー 、 フロントコントローラー間の相互作用を確立する方法は多数あります 。

• アクションは、要求への応答を返すResponderを直接呼び出すことができます。
• レスポンダーとレスポンスは、それらを直接呼び出すフロントコントローラーで利用できます。
• アクションはResponderを返すことができます。Responderが呼び出され、呼び出されてそれ自体を送信する応答を返します。
• などなど。

ADRパターンは、 フロントコントローラーの一部である可能性があるため、予備フィルタリングまたは要求検証の要素を記述しません。 予備フィルタリングとリクエストの検証のロジックに応じて、 アクションはResponderを呼び出すか、独自の応答を返すか、ロジックの操作の結果として追加のアクションを引き起こすなどのことに注意してください。 同様に、呼び出されたアクションは独自のチェックセットを持つことができ、 ドメインと対話することなくレスポンダーが呼び出されます。 このような「短縮」コールチェーンの理由は次のとおりです。

• HTTPメソッドの不整合。 ルーティングシステムが使用されたHTTPメソッドと要求されたActionの間の対応を見つけないなら、 フロントコントローラーはActionに要求を向ける代わりにエラー応答を返すかもしれません。
• 認証 クライアントアクセス権（およびその有効性）の有無は、このAction中にActionを呼び出すか、 ドメインと対話する必要性に影響を与える可能性があります。
• 認可 アクセス制御システムは、特定のActionに対するクライアントリクエストを拒否するか、 ドメインと対話せずにActionが実行され、場合によっては独自に応答を返すという事実につながる可能性があります。
• コンテンツの不一致。 フロントコントローラー 、 アクション、またはリクエストの処理に関係するその他の要素は、クライアントリクエストのAcceptヘッダーを確認できます。 / .
• . - , .

ADRは、独立したパターンではなく、Model-View-Controller pattern のコントローラーとビューのテーマのバリエーションと呼ぶことができます。次に、ActionはPage Controllerに似たバリエーションであり、このコンテキストでは、より正確な名前はAction Controllerである可能性があります。この場合、MVC のコントローラーに対応します。 （さらに、ページコントローラーの正式な説明では、それが「ページまたはアクション」であると述べられています）。同様に、回答者を考慮することができます







テンプレートビューまたはトランスフォームビューに類似したバリエーションとして、そしてそれを応答ビューと呼ぶのが賢明でしょう。したがって、レスポンダーはMVCのView要素に完全に適合します。



上記のすべてにもかかわらず、これらの代替の定式化は、個別のADRパターンのフレームワークでのアプローチの説明ほど良好で正確ではないと考えています。ほとんどの場合、モデルとビューの間の内部相互作用により、MVCではビューはモデルを更新しますが、ADRではレスポンダー は更新しませんドメイン。

あいまいなドメイン

ドメインには、アプリケーションクラスのセットだけでなく、その状態と環境の状態も含まれます。おそらくModelと呼ばれる可能性がありますが、これは混乱を追加するだけです。



さらに、アクションは、ドメインから受信したデータではなく、プレゼンテーションモデルを被告に送信する必要がある可能性があります。ただし、この場合、アクションによって呼び出されたドメインが、アプリケーションの状態をカプセル化したモデルビューを返す可能性があります。いずれにしても、ADRはMVCの改良版として提供されます。これに基づいて、私たちは約言うことができます



ADR のドメインは、MVCのモデルと同じです。

アクションの説明

コメントの1人は、着信リクエストに応じて異なるロジックが動作するようにアクションを編成できると指摘しました。たとえば、読者はActionを拡張し、異なるHTTPメソッドを操作するための機能を追加して、同じHTTPメソッドのロジックを同じActionに配置できることを提案しました。



私の意見では、パターン自体は各アクションが1つの機能のみを実行するという考えを表しており、これはコントローラーとアクション、およびADRとRMRパターンの比較から明らかに続きますが、より明確な形式で再度明確にします：意味それはすべての行動ですか 着信要求に応じて、アクションを1つだけ実行する必要があります。

MVCのファイナライズではなく、置換

ADRがサーバーアプリケーションに使用されるMVCの代替と見なされるべきネイトアイベルオブジェクト：

MVCパターンについて学べば学ぶほど、Webアプリケーションのサーバー側に適しているとは言えません。<...> ADRのあなたのアイデアの主なブレークスルーは、私には悪い抽象化と思われるものからの分離であると思います。絶対に必要でない限り、MVCの用語でADRを記述することは避けてください。

完全なコメント。

その他のコメント

このアイデアを説明する元のブログ投稿はこちらです。



Stefan Hochderfer はこの投稿で私の考えに答えました。こことredditでさらに議論が続けられました。



John LeightonがFocused Controllerについて書きました。これは、ADRのActionに非常によく似ています。RepresentationとRespondentを



比較する次の投稿はここにあり、redditに関するコメントはこことここにあります。コリタマアキヒトは、ここで彼のコメントを提供しています。

長所と短所

包括的な利点の1つは、パターンがWeb上で最も一般的な対話シナリオをより正確に記述することです。要求が来て、アクションにリダイレクトします。アクションはドメインと対話し、その後、応答が構築されます。ヘッダーとコンテンツの両方を含む応答作業は、アクション作業から完全に完全に分離されています。



複雑な欠陥の1つは、アプリケーション内のクラスの増加に対処する必要があることです。各Actionだけでなく、各Respondentも独自のクラスを受け取ります。



しかし、この欠陥は長期的にはそれほどひどくないでしょう。別個のクラスを作成する必要があると、継承階層がより明確になり、深くなりません。アクションの分離そして回答者は、より良いテスト容易性を促進します。異なるシステムでは、これらの機能はさまざまな方法で現れます。クラスの概要は通常、メソッドの概要よりも単純であるため、さまざまなコードエディタやIDEで「多くのクラス」を処理する方が「クラスを減らしてメソッドを増やす」よりも便利であることに気付きました。

感謝の気持ち

私は、質問、コメント、批判、または推奨事項とともに、この提案の作成に協力してくれたすべての人に感謝します。それとは別に、次の人々に感謝します。

• マシュー・ワイアー・オフィニー
• ハリkt
• ステファン・ホッホファー
• アダムカルプ
• ダン・ホリガン
• ジョシュ・ロックハート
• ボーシメンセン