1

私は現在、データベースを使用してページ オブジェクトをセットアップするカスタム フレームワーク内で作業しています。ページ オブジェクトには、フロント コントローラーが MVC (明らかに) パターン内でルーティングなどを処理するために使用するモジュール、ビュー、コントローラーなどに関する情報が含まれています。

データベース内でページを処理する最初の理由は、管理インターフェース内からオンザフライで新しいランディング ページを作成できるようにする必要があり、他の動的オブジェクトをアタッチできる onLoad および onUnload イベントも作成する必要があったためです。

しかし、昨日この投稿を読んだ後、この処理をデータベースの外に移動し、データベースをコンポーネントにすることなくページをテストできるように、すべてのファイル構造とコードを他のフレームワークのように駆動するべきではないかと考えました。

私は現在、カスタム フレームワークを廃止し、標準フレームワークの 1 つを使用してそれを拡張するかどうかを検討しています (これが現在最も可能性が高いことです)。または、フレームワークに付属するルーティング/処理メカニズムをそのまま使用する必要があるか?

4

1 に答える 1

3

通常、私は「おもちゃ」のアプリケーションで何を許可するかについてはかなり寛大ですが、何があっても避けなければならない悪い習慣がいくつかあると思います。データベースは強力なツールであり、必要な処理を実行するためのストアドプロシージャを介したかなり強力な言語を備えていますが、データへのアクセスの保存とスケーリング、および低レベルのデータ整合性ルールの適用には実際に使用する必要があります。

データ層にビジネスロジックを配置することは何年も前に一般的でしたが、関心の分離は、アプリケーションの存続期間にわたる保守性に本当に役立ちます。

ファイルシステムの代わりにデータベースを使用してページテンプレートを保存することに何の問題もないことに注意してください。将来的には、この2つの境界線はさらに曖昧になります。低予算のホスティングの問題と、動的に生成されたコンテンツの保存方法に問題があるため、すべてのテンプレートがデータベースにあるシステムが1つあります。フレームワークがファイルまたはフィールドからテンプレートを簡単に引き出して処理できる限り、どちらの方法でもそれほど重要ではありません。

一方、昨日の投稿は、データベースから直接UIレイヤー要素を生成することに関するものであり（少なくとも、私が読んだ方法です）、テンプレートの通常の保存場所ではありませんでした。これは、前述の理由から深刻な懸念事項です...データベースはWebアプリにロックされ、Webアプリのみにロックされます。

そして第3に、うまく機能し、拡張が容易なシステムを使用している場合は、他の人のアドバイスをあまり心に留めないでください。すべてのユースケースはわずかに異なります。保守性に問題がなく、ビジネスニーズに対応している場合は、それで十分です。

于 2008-10-30T15:51:22.710 に答える