6

Ruby on Rails 開発者として、Web アプリケーションを設計/実装する際に、問題のドメインから本質的な概念/エンティティを取得し、それらをモデルとして実装しています。通常、これらはベース ORM クラス (例: ActiveRecord::Base) から派生したクラスであり、データベース テーブルからレコードをマップし、モデルに関連するビジネス ロジックを実装する追加のメソッドを追加します。

このアプローチの利点は、問題のドメインからオブジェクトに関連するすべてのビジネス ロジックをすばやく見つけることができるため、モデル クラスが大きくない場合でも、アプリケーションのその部分がどのように機能するかを効率的に理解できることです。また、すべてのプレゼンテーション ロジックから分離されています。さらに、ORM のおかげで、ビジネス ロジック メソッドには DB 固有のコードがほとんど含まれていないため、非常にクリーンで読みやすくなっています。

不利な点は、そのようなクラスが巨大になることが多く、全体として理解するのが難しいことです。

だから私の質問は：

  • Clojure エコシステムは、OOP の ORM と同様の機能を果たすいくつかのライブラリを提供していますか?
  • そんなコードを整理する「Clojure流」とは？
  • アプローチの長所と短所は何ですか？
  • アプローチを説明し、正当化する記事/本/講演はありますか?
  • このアプローチを紹介するオープン ソース (サンプル) アプリケーションはありますか?
4

2 に答える 2

8

簡単に言えば、オブジェクトに何かをラップするのではなく、リスト、セット、マップなどのデータ構造で直接プログラミングします。そのため、ORM で行われた作業は、1 つのデータ構造を別のデータ構造に変換することになります。たとえば、user-row->user-record関数は、SQL データベースからポップした値のリストを、アプリのビジネス ロジックでユーザーを表すマップに変換する場合があります。ユーザーを保存するときは、逆関数を呼び出す必要があります。

経験豊富な OOP プログラマーが、物事の周りに式典がはるかに少ないという事実を「理解する」のは本当に難しいと言わざるを得ません。私たちの脳はこのアイデアと戦っているようです - 私見ですが、経験豊富な開発者/ソフトウェアアーキテクトにとっては単純すぎて未熟に思えるからです。:-)本当の専門家のように聞こえるように、奇妙な用語でいっぱいのより複雑な応答を記述できればいいのにと思いますが、追加することはそれほど多くないため、実際にはできません。:-)

ところで、小さいながらも興味深い点 - データ構造の広範な使用は、OOP の世界では間違っていると見なされている慣行です。たとえば、お金を単純なタプルに格納するのでは[10, "USD"]なく、比較、丸めなど、すべての通貨をカプセル化する本格的なものを記述する必要がありpublic class Moneyます。しかし、タプルを記述することは、FP で行うこととまったく同じです。これが OOP の世界から来ていることについて、私は奇妙な感覚を覚えていました。

コードの編成に関しては、OOP とほぼ同じ規則が名前空間に関して適用されます。Java パッケージの場合と同様に、トピックに基づいてコードを整理します。ただし、すべての関数 (メソッドの呼び出しに使用) がステートレスになり、通常は上記のユーザー レコードなどを引数として取ります。したがって、の状態を変更する代わりにfoo.barChange()、(bar foo)純粋な関数barが新しいデータ構造を返す代わりに、 .foo2foo

そうは言っても、OOP の利点の 1 つは、このパラダイムを使用して記述された多くのアプリケーションがあるだけでなく、さらに重要なことに、複数世代のアプローチが試行されていることです (これが、今日の DI コンテナーの人気などに到達した方法です)。 ...)。関数型プログラミングにはまだこれがありません。基本的に、FP でアプリのアーキテクチャを実行する方法について、証明された最終的なマニュアルを持っている人は誰もいません。ところで、これが、人々が大きなフレームワークを書くことを思いとどまらせ、データ変換機能にとどまることを奨励する理由です。そうすれば、いつでも好きなように接続して、構造上の落とし穴を避けることができます。

于 2013-10-04T14:17:56.340 に答える
8

Clojure の開発の背後にある原動力となる哲学の 1 つは、複雑なものを合理的な範囲で最大限に分離し、データをデータとして扱い、データの結合を避け、値の状態と IDを分離することです。

  • Clojure エコシステムは、OOP の ORM と同様の機能を果たすいくつかのライブラリを提供していますか? あるデータ構造を別のデータ構造に変換する純粋な関数を使用してデータを処理したいという願望により、一部の clojure プログラマーは ORM を敬遠しますが、本当に望むならClojure で Hibernate を使用できない理由はありません。

  • そんなコードを整理する「Clojure流」とは？このトピックに関する Amit Rathore のプレゼンテーションが好きです

  • アプローチの長所と短所は何ですか？Rich Hickey は、この古典的なビデオでこれらのアイデアについて優れたディスカッションを行っています。
  • アプローチを説明し、正当化する記事/本/講演はありますか? 私は個人的に The Joy of Clojureをお勧めします。
于 2013-10-03T21:03:12.627 に答える