53

私は現在、次の 4 つの部分に分かれた Rails 3 プロジェクトに取り組んでいます。

  • 公開ウェブサイト
  • 管理ウェブサイト/バックエンド
  • モデル
  • サードパーティ データ アクセス用の API

モデルは 3 つの主要コンポーネント間で共有されるため、それらを 1 つのメイン プロジェクトに含めないようにしたいと考えています。ただし、各パーツはモデルにアクセスする必要がありますが、コードを繰り返したり、どこでも異なるバージョンを使用したりしたくありません。

現在、モデル コードは gem にあり、各プロジェクトの Gemfile では、次の行でそれらを参照しています。

gem "my_models", :path => "../my_models/"

ただし、同僚がシステムを評価するためにテストサーバーにデプロイするときは、外部リポジトリからモデルをプルする必要があるため、上記の行を次の行に置き換えます。

gem "my_models", :git => "git@private.repository.com:username/my_models.git"

これ自体はうまく機能しますが、「バージョン」に関してはかなり不格好です (つまり、テスト サーバーに変更をデプロイするたびにバージョンを上げる必要があります)。ローカルではなく git を使用するように行を切り替えます。ファイルを適切にプッシュしていることを確認してください。

以前は、共有の git サブモジュールを使用していましたが、これも同様に厄介でした。

私はすべてを 1 つの巨大プロジェクトに組み込むことは避けたいと考えています。なぜなら、これらは巨大で保守が困難になる傾向があるからです。また、可能であれば懸念事項を分離したいと考えています。他のコンポーネントに影響を与える可能性があります - 明らかにモデルが問題を引き起こす可能性がありますが、それは私が検討し理解しているリスクです.

このようなことになると、そこにいる人々は何を提案しますか? それとも、私はそれを完全に間違った方法で行っていますか?

いくつかの追加の背景:

このアプリは、「すべてを 1 つのプロジェクトにまとめる」というモデルに従った既存の Web サイトを書き直したものです。残念ながら、ここには 2 つの問題があります。

  1. アプリの開発が不十分でした - 私はこのプロジェクトを継承しましたが、最初にそれを手にしたとき、読み込み時間は 1 人のユーザーでページあたり約 2 分でした - これはその後短縮されましたが、まだ問題があります
  2. 現在、現在のサイトのキャパシティ制限に達しており、今後 6 か月でさらに多くの負荷をかける必要があると予想しています。ただし、「オールインワン」アプリでスケールアウトすると、スケールアウトにリソースが浪費されることになります。それを必要としないサイトのバックエンド。

基本的に、私が分離したいものは 2 つあります。フロント エンド (公開 Web サイトと API) とバック エンドです。ソフトウェア開発について私が知っていることは、これらすべてを組み合わせることは理想的なソリューションではないことを示しています (そして過去の歴史が示しています)。これら2つを分割することは、フロントエンドのパフォーマンスを確保するという点で良い動きだと思います)。

おそらく、これを別の角度から見る必要があります。モデルを各プロジェクトに保持し、プロジェクト間でモデルを共有する代わりに、機能領域ごとに機能のサブセットを削減します (つまり、バックエンドは誰が投稿を作成したかを知る必要がありますが、フロントエンドはそれをあまり気にしないので、モデルを読み込むときはそのロジックを省略してください)。

4

6 に答える 6

20

モデルプロジェクトをドロップし(モデルを他の部分の1つに入れます。「より重要」と考えるものは何でもお勧めします)、すべてのプロジェクトを単一のリポジトリ(個別のプロジェクトフォルダー)に入れ、models/libs/apis/whateverへのシンボリックリンクを作成します

コードが高度に結合されており、一度にいくつかのプロジェクトを変更する必要があることがよくあります (モデルの更新やそれらを使用する API の更新など)。

シングル リポジトリ シンボリック リンク セットアップの良い点の 1 つは、コミットの断片化が少なくなり、通常は完全な機能の実装を表すことです。バグの追跡、履歴の読み取り、コードベースの維持が容易になります。

また、展開するときに、多くのリポジトリから読み取る必要はありません。障害点が 1 つ減ります。

ブランチがすべてのプロジェクトのスコープを保持するなどのモデルにより、リリース プロセスもよりシンプルになります。

Windowsなどではシンボリックリンクがうまく機能しないなどの欠点がありますが、私にとっては完全に機能します

于 2012-06-27T21:26:45.737 に答える
8

共有モデルを含むマウント可能なエンジンを作成し、そこからgemを作成できます。これにより、名前の間隔の問題がエレガントに処理されます。ここでの他の素晴らしい側面は、あなたがあなたの資産も共有することができるということです。

詳細については、このrailscastをご覧ください。

于 2012-06-29T01:15:36.780 に答える
3

テストが必要な変更をリモート リポジトリにプッシュして「バージョン」を管理する必要がありますがlocal、Bundler 1.2の新しい構成を使用できます。

http://gembundler.com/man/bundle-config.1.html#LOCAL-GIT-REPOS

これにより、ローカル コミットが取得され、デプロイ時に Gemfile を変更し続ける必要がなくなります。

于 2012-10-14T20:36:32.213 に答える
0

プロジェクトのコード カバレッジは十分ですか? もしそうなら、私は理にかなったロジックを分離しようとします.モデルが異なるプロジェクトで使用されている場合は、最も適したものを選択し、その上にAPIを記述します.

次に、その API を使用して、他のプロジェクトのモデルにアクセスできます (できれば ActiveModel などを使用します)。単純な CRUD は引き続き使用できますが、すべてのコア モデル ロジックは外部で処理されます。

ただし、それらを分割する前によく考えてください。バラバラにしたい Behemoth から作成する各アプリで、ドメインをタイトに保ちたいと考えています。

エンジンについて:

同じ問題にエンジンを使用しましたが、それは役に立ちますが、開発時にローカルパスを指すようにGemfileを変更し、gemをプッシュしてから現在のプロジェクトにプルする必要がありました。好きではない。

于 2012-06-29T01:45:01.383 に答える
0

これがあなたの特定の問題の解決策ではないことはわかっています。しかし、すべてのプロジェクトを 1 つに統合することを強くお勧めします。このすべての部分を 1 つのアプリケーションに含めることは非常に一般的であり、オーバーヘッドはありません。この問題に対する厄介な解決策はないと思います。

于 2011-08-11T11:19:16.003 に答える