2

ホワイト ラベルのサーバー側アプリケーションを開始しようとしていますが、すぐにコーディングを開始したくありません。これは、少なくとも最初からではなく、これまで行う必要がなかったことであり、今回は私が管理しています。

私は多くのアプリケーションに取り組んできましたが、良いものも悪いものもありませんでしたが、ほとんどの場合、アーキテクチャの観点からアプリケーションの背後にある思考の欠如に常に気付きました。これは誰かを反映したものではありません。ほとんどの場合、電話をかけるビジネスに縛られています。ともかく...

私は mysql を使用して Railo、Coldbox、および AngularJs を使用することにしました。しかし、これは議論のポイントではなく、FYI です。

私が助けを求めているのは、コア コードとカスタム コードを保持できるようにサイトを設計する方法です (これをクライアント コードと呼びます)。はい、残念ながらこれを調査しましたが、これにアプローチする方法についてはあまり話されていません。

これはどういう意味ですか?1 セットのコード ファイルを複数のクライアントで使用できるサイトの基本的なシェルが必要です。たとえば、登録、会社の詳細、ログイン、言語設定などを行うモジュールが必要です。ただし、すべてのクライアントには常に要求があります。カスタマイズのために、クライアントコードを使用してコアコードをオーバーライドする機能が必要です。

Coldbox の基本 (つまり、1 つのコードベースと 1 つのサイト) について十分な知識がありますが、目標を達成するには十分ではありません。

これは Coldbox アプリの基本構造であり、これがクライアント ディレクトリ構造の見方です。

+ApplicationRoot
|---+ 構成
|---+ フレームワーク
|---+ ハンドラー
|---+ プラグイン
|---+ レイアウト
|---+ ビュー
|---+ インクルード
|---+ インターセプター
|---+ モデル
|---+ モジュール
|---+ Application.cfc
|---+ index.cfm

上記が 1 つのクライアント アプリケーションの基本構造である場合、それはコア コードにどのように拡張されますか? 心に留めておいて、コアコードはモジュールのdao、サービス、ゲートウェイ、Beanを保持すると考えています。これらはどこに存在し、コア コードは他のフォルダに同様の構造を持っていますか?

+ApplicationRoot
|-----+ コアコード
|-----+ フレームワーク
|-----+ プラグイン
|-----+ インターセプター
|-----+ ビュー
|-----+ モデル
| ---+ モジュール

---+ クライアント 1
|-----+ 上記のクライアント ディレクトリ構造による

---+ クライアント 2
|-----+ 上記のクライアント ディレクトリ構造による

これを読んでくれてありがとう。正しい方向に私を導いてくれることを願っています。

4

1 に答える 1