問題タブ [modularity]

別の同様のトピック (stackoverflow-serverfault-superuser など) に拡張したい Web サイト (ASP.NET MVC) があります。

データベース レイヤーとコントローラー レイヤーは、両方の Web サイトで同じです。異なるのはビュー レイヤーだけで、ロゴ、マスターページ、一部のリソース ファイル (一部)、および CSS などの詳細のみが異なります。

この状況を管理する最善の方法は何ですか? ジェフと彼のチームはどのようにこれを達成しましたか?

私の理想的な目標は、単一のソリューション (Visual Studio ソリューション)、コントローラーとモデルを含むプロジェクト、および n 個の異なるプロジェクト (各ビューごと) を持つことです。（明確にするためにこの行を追加しました）

これは、2 つのソリューションを (SVN または Mercurial を使用して) 分岐し、公開中にマージするだけで完了しますか?

みんなありがとう！

コードをゼロから書き始めると、すべてを 1 つの関数にすばやく書き込んでしまうという悪い癖があります。その後、製品が動作するようになり、それを修正しようとすると、関数を作成し、何を渡す必要があるかを把握する必要があります。

プロジェクトがほぼ完了したときにクラスを再設計することが非常に困難になるため、最悪の事態になります。たとえば、通常、コードを書き始める前に計画を立てます。プロジェクトが完了したときに、クラスをよりモジュール化したり、継承を使用したりできたはずだと気づきました。基本的に、私は十分な計画を立てていないと思います。また、1 レベル以上の抽象化も行っていません。

結局、私は大きなメイン関数、1 つのクラス、およびいくつかのヘルパー関数を含むプログラムに行き詰まっています。言うまでもなく、再利用性はあまり高くありません。

誰かが同じ問題を抱えていて、これを克服するためのヒントはありますか? 私が念頭に置いていたことの 1 つは、メイン関数を疑似コードで作成することでした (詳細はあまりありませんが、必要なオブジェクトと関数を確認するには十分です)。基本的にトップダウンのアプローチです。

これは良い考えですか？他の提案はありますか？

新しいJ2EEベースのエンタープライズフレームワークを設計する場合、別々のビジネスモジュールが異なるデータベースを使用し、異なるアプリケーションサーバーインスタンスで実行する必要がある状況に備える必要がありますか？

別の観点から：モジュールごとに異なるデータベースとサーバーの実際の要件を経験したことがありますか？はいの場合、その企業の規模はどのくらいでしたか？

（私が見る限り）これは物事をはるかに複雑にし、このフレームワークの以前のバージョン（および小規模な銀行）では、上記のケースは決して起こりませんでした。

返信ありがとうございます！

私たちは、非公開にしたいいくつかの独自のアルゴリズムと機密性の高いロジックを使用して、Python で新しいプロジェクトを開始しています。また、コードに取り組んでいる数人の部外者 (一般の一部のメンバー) も参加します。部外者にコードの小さなプライベート ビットへのアクセスを許可することはできませんが、パブリック バージョンが十分に機能することを望んでいます。

私たちのプロジェクト Foo には、bar1 つの関数 を持つモジュール があるとしますget_sauce()。で実際に何が起こるかget_sauce()は秘密ですが、 の公開バージョンがget_sauce()、間違っていても許容できる結果を返すことを望んでいます。

また、独自の Subversion サーバーを実行しているため、誰が何にアクセスできるかを完全に制御できます。

シンボリックリンク

私が最初に考えたのはシンボリック リンクでしbar.pyた。残念ながら、シンボリック リンクの作成は面倒な手作業です。特に、これらのプライベート モジュールが実際に 20 個ほどになる場合はなおさらです。bar_public.pybar_private.py

さらに重要なことに、Subversion authz ファイルの管理が難しくなります。これは、保護したいモジュールごとに例外をサーバーに追加する必要があるためです。誰かがこれを行うのを忘れて、誤ってシークレットをチェックインする可能性があります...その後、モジュールはリポジトリにあり、それなしでリポジトリを再構築する必要があり、その間に部外者がそれをダウンロードしないことを願っています.

複数のリポジトリ

次に考えたのは、2 つのリポジトリを用意することでした。

private/内部開発者だけが と の両方をチェックアウトできるようにするという考え方ですpublic/。社内の開発者は自分の を設定しPYTHONPATH=private/trunk:public/trunkますが、それ以外の人は を設定するだけですPYTHONPATH=public/trunk。そうすれば、インサイダーとアウトサイダーの両方from foo import barが適切なモジュールを取得できますよね?

これを試してみましょう：

私は Python の専門家ではありませんが、Python はモジュールfooとそれに関連する検索についてすでに決心しているようです。

削除しても役に立ちませんfoo：

より良い解決策や提案を教えていただけますか?

I have some Java programs, now I want to find out whether it is modular or not, if it is modular then up to what extent, because modularity can never be binary term i.e. 0 or 1. How do I decide that particular code is modular upto this much extent. I want to know how to make code much more modular?

私はPrismのガイダンスを読み進め、彼らのコミュニケーション手段のほとんどを把握できたと思います。

コマンドは非常に単純なので、DelegateCommandは、ビューをそのモデルに接続するためだけに使用されることは明らかです。

クロスモジュール通信に関しては、特に複合コマンドでEventAggregationを使用する場合は、やや明確ではありません。

実用的な効果は同じです例えば

• イベントを公開する->すべてのサブスクライバーが通知を受け取り、それに応じてコードを実行する
• 複合コマンドを実行します->登録されているすべてのコマンドが実行され、それに付随するコードが実行されます

どちらも「ファイアアンドフォーゲット」の方針に沿って機能します。つまり、イベントの発生/コマンドの実行後、サブスクライバーからの応答を気にしません。

両方の実装（内部）は非常に異なることは理解していますが、実際の使用法の違いを理解するのに苦労しています。

それで、それが実際に何を意味するのかを考える必要があります-イベント？それは何かが起こったとき（イベントが起こったとき）ですか？「Webリクエストが完了しました」のように、ユーザーが直接リクエストしなかったものはありますか？

そしてコマンド？これは、ユーザーが何かをクリックしてアプリケーションにコマンドを発行し、サービスを直接要求したことを意味しますか？

それですか？または、これらの通信手段の1つを他の通信手段よりも使用するタイミングを決定する他の方法はありますか。ガイダンスは、私が読んだ最高のドキュメントの1つですが、具体的な説明はありません。

ですから、Prismに関係している/使用している人々が、これに光を当てるのに役立つことを願っています。

MSDNから:

モジュール内のほとんどのビューを直接表示する必要はなく、ユーザーによるなんらかのアクションの後にのみ表示する必要があります。アプリケーションのスタイルによっては、ユーザーがビューにアクセスするために、メニュー、ツールバー、またはその他のナビゲーション戦略を使用したい場合があります。モジュールの初期化メソッドでは、アプリケーションのナビゲーション構造に登録することもできます。ナビゲーション構造のイベント ハンドラー (つまり、ユーザーがメニュー項目をクリックしたとき) では、ビュー インジェクション手法を使用して適切な領域にビューを追加できます。

同様のシナリオがあります。RegisterViewWithRegion を使用して、モジュールの初期化メソッドでビューをリージョンに追加しています。メニュー (別のモジュール) とのビュー ベースのユーザー インタラクションを表示したいと思います。

Prism のモジュールの分離された動作を壊さずにこの動作を実現するにはどうすればよいですか?

ModuleB から ModuleA によって、リージョンに追加されたビューをアクティブ化/表示することは可能ですか?

Rails アプリケーションをモジュール化する方法を探しています。私が見たように、それを達成するための組み込みの方法はありません。さまざまなプラグイン/コア ハックを見つけましたが、それらの動作方法と成熟度について信頼できないと感じています。

これについて何か経験はありますか？

これまでのところ、私はこれを見つけました：

• 砂漠: http://github.com/pivotal/desert
• Rails エンジン: http://rails-engines.org/

私のデータベース設計では、テーブルの「クラスター」を持つ傾向があります。これらのクラスターは通常、1 つのアプリケーションまたは機能的に密接に関連するアプリケーションのグループをサポートします。多くの場合、これらのクラスターは、比較的少数の外部キーを介して相互に関連付けられます。これにより、ビジネス内の独立したアプリケーションを相互に統合することができます。

たとえば、「Foo」、「Bar」、「Baz」というアプリケーションがあり、それぞれに複数のテーブルがあるとします。テーブルとその外部キー参照のリストは次のとおりです。

• FooTableOne
• FooTableTwo -> FooTableOne
• BarTableOne -> FooTableTwo
• BarTableTwo -> BarTableone
• バズテーブルワン
• BazTableTwo -> FooTableTwo、BazTableOne

現在、LINQ-to-SQL を使用してこれらのテーブルにアクセスしています。クラスター (Foo、Bar、および Baz) ごとに個別のプロジェクトがあり、これらの各プロジェクトには、クラスター内のすべてのテーブルの .dbml があります。ここでの考え方は、クラスターを使用する各 (1 つ以上の) アプリケーションが、必要な LINQ クラスを含む共有ライブラリをインポートできるということです。

これは良い考えかもしれませんし、そうでないかもしれません。陪審 は まだ 出ていないようです。私が本当に疑問に思っているのは、異なるコンテキスト クラスに存在するにもかかわらず、別のクラスター内のクラスによって表現されるクラスター間の参照を持つことができるかどうかです。(より具体的には、Visual Studio でこの関係を作成する方法)。

例に戻ると、次のようにしたいと思います。

• プロジェクト・フー
  • Foo.dbml
  • FooDataContext
  • FooTableOne
    • FooTableOne.FooTableTwos
  • FooTableTwo
    • FooTableTwo.FooTableOne
    • FooTableTwo.BarTableOnes (これはそれほど重要ではありません)
    • FooTableTwo.BazTableTwos (これはそれほど重要ではありません)
• プロジェクトバー
  • Bar.dbml
  • BarDataContext
  • バーテーブルワン
    • BarTableOne.FooTableTwo
    • BarTableOne.BarTableTwos
  • BarTableTwo
    • BarTableTwo.BarTableOne
• プロジェクトバズ
  • Baz.dbml
  • BazDataContext
  • バズテーブルワン
    • BazTableOne.BazTableTwos
  • バズテーブルツー
    • BazTableTwo.FooTableTwo
    • BazTableTwo.BazTableOne

アウト オブ コンテキスト エンティティへの参照はすべてオブジェクトではなく単純な ID (int) であり、アウト オブ コンテキスト エンティティへのコレクションはまったく存在しません。これらのクラスに独自のメソッドを追加して、(コンテキストのインスタンスを指定して) 適切なルックアップを実行できることはわかっていますが、もう少し合理化して一貫性を持たせたいと考えています。

このコンテキスト/クラスターの分離により、アプリケーション間のモジュール性が得られることに注意してください。したがって、たとえば、Baz アプリケーションは Baz および Foo コンテキストのみをインポートする必要があり (Baz は Foo に依存しているため)、Bar はインポートしません。(これは、Foo に Bar エンティティのコレクションがないことを前提としていますが、これは問題ありません)。これは良いことですが、重要ではありません。LINQ/VS でこれが簡単にできない場合は、モジュール性を破棄して 1 つの大きなコンテキストを使用することを検討します。