私のWEBデザイン契約
WEB開発におけるデータベースは重要な仕事である.
良好な設計は開発作業にとって極めて重要である.
私はずっと簡潔で、規範化された、コードフロー化可能な設計を求めています.
今日やっと模索させてもらいました.
データベースのテーブルはこのように設計されています表名、フィールド名全小文字 テーブルbのフィールドb 1データは、テーブルaのフィールドa 1からの場合、b 1:a_と命名される.a 1、データの合法性検査を提出するために便利な を提供することを目的とする.データベースが注釈comentをサポートする場合.では、チェックルールを直接comentに書きます.書き方については、個人の習慣を見てみましょう.もちろん、このルールは最終的には異なる言語のチェックコードにエクスポートされます.
データベース・データのコミット・フォーマット(データは関連配列として提供されます)は、このように定義されます.関連配列のkeyはフィールドを表し、valueは関連パラメータ を表す. key SELECT/UPDATEと小文字のWHERE条件 key UPDATE/INSERTと大文字のfield値ペア定義 keyはSELECTの戻りフィールドとして混在しており、実際の作業では、私は特殊なkey==*で処理しています.これにより が便利になります. key==""は、limit、orderなどの拡張SQL文です.もちろん、詳細なデザインは です.
このインタフェースを実現するのは難しくありません.このインタフェースの意味が明確なので、よく使われるSQL文要求を適用することができます.もちろん、このインタフェースも万能ではありません.複雑なSQL文の動作には特殊な処理が必要です.
データベース操作クラスのインタフェース設計まず、ビジネスロジックと上記のフォーマット定義に基づいて、データ有効性チェックフロントエンドコードを設計し、データチェックが通過した後の を設計しなければならない.オペレーティングクラスは、上記のフォーマット定義設計に基づいて、一般的なSQL文 を自動的に生成することができる.
ビジネスロジックの問題(すなわちインタフェース設計の1)ユーザーロールに基づいて、設計関数名が一致し、内容が異なるインタフェース関数 フロントでコミットされたデータには、インタフェース関数に対応する論理が必要です.この簡単さはパラメータ問題 です.
この点はphpの例を挙げる
説明、実は検証コードにとって、完全に統一して検証できるので、action関数で検証する必要はありません.そうすると、action関数を定義するときに、あるaction関数を検証してから実行する必要がある場合は、これらの関数定義をすべてパッケージ化します.
検証していなければ、実行期間に対応するaction関数がないので、エラー処理は別です.
同様に、ユーザの役割によってインタフェース関数(action)の実行体を設定したり、いっそこのaction関数があるかどうかを設定することができる.
同様に,この方法に基づいてaction関数を異なる状態フラグで定義できる.
実はこの方法は運転状態によってactionインタフェースを判定するので、sessionの中の重要な状態を判定条件にすることができます
このような契約を経て、フロントのactionデータがバックグラウンドに提出された後、これらの段階を経てフロントエンドの統一処理、例えばsession、cookie、検査検証コードなど actionに従って対応するモジュール に呼び出す.モジュール運転状態に基づいてactionインタフェース関数 を定義する. actionコミットデータの有効性チェック、これは複雑で、 が適用されていることを見てください. actionインタフェース関数 を実行する.
actionインタフェース関数の内容は何ですか?もちろん、主に出力方法と関連行為の処理を担当していますが、ヘッダのデータベースSQLの操作は簡単です.ほとんどactionデータをデータベース操作クラスに完全に転送すれば終わりです.(もちろん複雑な業務はいつも単独で処理しなければならない)
この文章を読む人の99%は霧だと思います.はっきり見えるかどうかにかかわらず、まずなぜこのように設計されているのかと聞かれます.
私の文章をよく読んで、振り返ってみると、私の方法を参考にすれば、次のことがわかります.
私が提供したのはポリシーで、契約ですが、決してフレームワークライブラリではありません.
人に魚を授けるより漁を授けるほうがましだ
そして、私が私のコードをあなたにあげても、おそらく役に立つのはそのデータベースインタフェースクラスの設計だけで、他のアプリケーションはあなたのアプリケーションには役に立たないでしょう.それはビジネスロジックに基づいてカスタマイズして書くからです.どのフレームワークライブラリでも書くコードは避けられない.
少しフレームライブラリの無駄な味がします
良好な設計は開発作業にとって極めて重要である.
私はずっと簡潔で、規範化された、コードフロー化可能な設計を求めています.
今日やっと模索させてもらいました.
データベースのテーブルはこのように設計されています
データベース・データのコミット・フォーマット(データは関連配列として提供されます)は、このように定義されます.
このインタフェースを実現するのは難しくありません.このインタフェースの意味が明確なので、よく使われるSQL文要求を適用することができます.もちろん、このインタフェースも万能ではありません.複雑なSQL文の動作には特殊な処理が必要です.
データベース操作クラスのインタフェース設計
ビジネスロジックの問題(すなわちインタフェース設計の1)
この点はphpの例を挙げる
if($ValidateCode){//
if($userrole==0){// (action)
function query(){
something;
}
}
if($userrole==1){
function query(){
something;
}
}
}else{
function foo(){}
}
説明、実は検証コードにとって、完全に統一して検証できるので、action関数で検証する必要はありません.そうすると、action関数を定義するときに、あるaction関数を検証してから実行する必要がある場合は、これらの関数定義をすべてパッケージ化します.
if($ValidateCode)// 検証していなければ、実行期間に対応するaction関数がないので、エラー処理は別です.
同様に、ユーザの役割によってインタフェース関数(action)の実行体を設定したり、いっそこのaction関数があるかどうかを設定することができる.
同様に,この方法に基づいてaction関数を異なる状態フラグで定義できる.
実はこの方法は運転状態によってactionインタフェースを判定するので、sessionの中の重要な状態を判定条件にすることができます
このような契約を経て、フロントのactionデータがバックグラウンドに提出された後、これらの段階を経て
actionインタフェース関数の内容は何ですか?もちろん、主に出力方法と関連行為の処理を担当していますが、ヘッダのデータベースSQLの操作は簡単です.ほとんどactionデータをデータベース操作クラスに完全に転送すれば終わりです.(もちろん複雑な業務はいつも単独で処理しなければならない)
この文章を読む人の99%は霧だと思います.はっきり見えるかどうかにかかわらず、まずなぜこのように設計されているのかと聞かれます.
私の文章をよく読んで、振り返ってみると、私の方法を参考にすれば、次のことがわかります.
私が提供したのはポリシーで、契約ですが、決してフレームワークライブラリではありません.
人に魚を授けるより漁を授けるほうがましだ
そして、私が私のコードをあなたにあげても、おそらく役に立つのはそのデータベースインタフェースクラスの設計だけで、他のアプリケーションはあなたのアプリケーションには役に立たないでしょう.それはビジネスロジックに基づいてカスタマイズして書くからです.どのフレームワークライブラリでも書くコードは避けられない.
少しフレームライブラリの無駄な味がします