2

複数の Web アプリケーション用の UI フレームワークを設計しようとしていますが、状況に応じたインフラストラクチャの設計に問題があります。

  • asp.net mvc でビルドされた 7 つ (またはそれ以上) の分離された Web アプリケーション
  • 一部の Web アプリケーションは内部サーバー上にあり、一部はホストされています
  • すべて同じ基本的な css/images/javascript を使用 (各アプリケーションが使用できる共有コンポーネント)
  • すべてのアプリケーションには独自の css と javascript があります
  • すべてのアプリケーションには、独自の TFS ブランチとソリューションがあります
  • すべてのアプリケーションには、独自のリリース管理 (毎月/毎年/など) があります。

私が達成したいこと:

  • すべてのアプリケーションではなく、UI のバグを 1 回修正する
  • すべてのアプリケーションで一貫した UI
  • UI のことで他の開発者に迷惑をかけないでください

スマートインフラとは？

4

2 に答える 2

1

私の経験では、Web プロジェクト間でコンパイルされていないコードを共有することの難しさは、ほとんどがソース管理の問題です。内部の NuGet サーバーを使用してコンパイル済みコードを共有していますが、これはコンパイルされていないコードではうまく機能しません。このようなもの (HTML、sript、コンテンツ) については、フレームワークのすべての共通コンポーネントを、独立したプロジェクトまたはサブモジュールとして、使用するソース管理システムに保存できる単一の階層に保持するのが最も簡単だと思います。

/myframework/scripts
/myframework/styles
/myframework/images

「myframework」がサブモジュールとして管理されている場合、それを含めるプロジェクトとは別に維持できるはずです。これは、git と svn を使用すると簡単です。

アプリケーション固有のスクリプトとコンテンツは、通常どおり好きな通常の階層に保持できます。

/scripts
/styles
/images

また、一般的なフロントエンド フレームワークがデフォルト構成でどのようにセットアップされているかを確認することもできます。たとえば、Zurb Foundationは一連のスクリプト、スタイル、およびコンテンツ テンプレートを提供しています。すべてがデフォルトでフォルダーの下に保存されContent、Javascriptsスタイルシートを変更するのではなく、カスタムの場合は別のスタイルシートでスタイルをオーバーライドするようにアドバイスしています. これにより、共有フレームワークへの変更から保護されます。独自の内部フレームワークに同様のポリシーを適用することは理にかなっているようです。

于 2013-01-03T08:29:08.800 に答える
0

NuGet を使用して、css/js/images をすべての異なるプロジェクトに配布することになりました。グローバル UI には、内部 nuget サーバーへの自動化された nuget パッケージ作成を伴う独自のチーム プロジェクトがあります。

于 2013-01-08T09:21:04.847 に答える