4

ASP.NETMVCアプリケーションとJavaWebアプリケーションでは、ビジネスロジックを別のパッケージ/ dllに保持し、データベースや配信メカニズム（Webアプリケーション、Webサービス、ネイティブモバイルまたはデスクトップなど）を次のように扱うという一般的な方法があります。プラグインされている詳細。

私が言えるこのタイプの構造化の利点のいくつかは次のとおりです。

  • さまざまな配信メカニズムまたは永続化レイヤーを使用したビジネスロジックの再利用
  • Webフレームワークをロードしたり、データベースに接続したりしなくても、ビジネスロジックの受け入れテストと単体テストを実行できます。テストは非常に高速です
  • アプリケーションがどのように配信されるかではなく、それが何であるかという観点からアプリケーションを考える

しかし、この慣行はRailsコミュニティでは一般的ではありません。ビジネスロジックがgemに保持され、メインのORMがすべて永続ロジックとビジネスロジックを結び付けているRailsアプリケーションは見当たりません。私が述べたようにアプリケーションを構造化する必要がないRubyについて何かありますか？

4

3 に答える 3

3

「必要」を定義します。.NETまたはJavaでこれを行う必要はありません。便利です。

Railsアプリは、多くの場合、単一のアプリ内でWebアプリと関連サービスのみを完全に公開します。

テストも同様です。コードを個別にテストするためにアプリケーションの機能を分割する必要はありません。Railsでのテストも例外ではありません。コードの任意のレベルで実行できる単体テストや仕様など、および任意の部分をモックアウトするさまざまなメカニズムがあります。機能の。

永続性レイヤーは通常ARレイヤーによって処理されますが、実際には永続性レイヤーを実際に切り替えることはかなり珍しいことです（私は、開発の30年に1回だけ切り替えましたが、それは明らかに逸話です）。さらに、Rubyのこのようなスイッチの一部は、ダックタイピングのためにコードレベルで透過的です（たとえば、ActiveRecordではなくActiveResourceに移動することで、1つのアプリをローカルDBからサービスにほぼ透過的に切り替えましたが、後で何かを最適化すると、データモデルは非常に単純になりました。）

とはいえ、IMO the Railsコミュニティは、「エンタープライズ」ショップの慣習を見落としがちです。Ruby-the-languageを使用すると、過剰に設計することなく機能を簡単に構築できるからです。ただし、これの制限は、アプリが特定のサイズに達した後にのみ明らかになります。

RubyとRailsの開発における最近の傾向には、私が企業で何年にもわたって行ってきたことが含まれます（たとえば、JavaよりもRubyでの実装がはるかに簡単です）。ただし、それ自体のために機能をライブラリに分割することは、特に有用ではありません。分割する必要のあるコードを特定することは重要ですが、それは必要に応じて環境全体で行われます。

于 2013-01-21T22:13:34.700 に答える
0

Railsは、設定より規約がすべてです。そして、その意見/ベストプラクティスが示されています。

BLLをGemsに分解することに大きな利点はありません。Webアプリから独立していて、再利用できるコードがない限り。たとえば、最近、会社のフォーラム用にBBCodeパーサーを作成したので、それを任意のRailsアプリにプラグインできるGEMとしてパッケージ化しました。githubには、レールを機能的に拡張する何千ものGEMがあります。

Railsアプリ用のGEMを作成するという全体的なアイデアは、コードの再利用である必要があります。より多くのコード分離を試みるためだけにコードを分離している場合は、レールの規則に依存していません。他のレール開発者がプロ​​ジェクトに参加した場合、学習曲線があります。

RailsにWebフレームワークをロードしないテストシステムをいくつでも使用できます。非常に大きなトピックでテストすることで、RSpecなどを調べます。また、テストを高速化する方法がいくつかあります（GuardやSporkの使用など）。

それはすべてアプリに本当に依存します。Railsのアイデアは、アプリケーションをすばやく完成させることです。私の経験では、Javaの開発は非常に遅いものでした。ASPについても同じです。しかし、それらは単に「悪い経験」だったのかもしれません。たくさんの人が両方を誓います。

于 2013-01-21T22:10:18.397 に答える
0

ほとんどの場合、それは努力と構成に関するものです。個々のポイントを分解してみましょう：

作業：新しいgemのセットアップには少し時間がかかります（すべてのプロジェクトには、テスト、モック、ドキュメントなど、独自の依存関係のセットがあります）

構成：ほとんどのRailsアプリはActiveRecordを使用するため。モデルレイヤーを分割するのは少し難しいです（ただし、多く の 宝石がこれを行います）。 Rails::Engineただし、その周りの痛みを軽減するのに大いに役立ちます。

コスト：ほとんどのRailsプロジェクトでは、コードを個別のgem/repoに分割することで得られるものはほとんどありません。

  • ほとんどのプロジェクトは相互にコードを共有していません（共有する場合は、gemをセットアップします）

  • コードをテストする方法に違いはありません-または適切な設定であるはずです-。宝石またはメインプロジェクトのいずれかで。（コントローラーなどにぶつかることなくモデルをテストできます-問題ありません）

  • 主な利点は、インターフェイス/レイヤー間に明示的なコントラクトを適用することです。これは、Rubyコミュニティではあまり一般的ではありません。

于 2013-01-21T22:15:45.560 に答える