いままでの開発は、一応手続きを考えてから、プログラムに入りました。
というのも、
画面をプログラムする際には、
どのような関数を呼び出すかが決まっていないと、呼び出せないし、
画面の出力をしたければ、データ表示方法がきまってるわけで、
そのためには、DBからどのデータを取ってきて、どう処理するか
きまってないといけない。
つまり、画面をプログラミングする前に、処理やDBをどうするか、ある程度
決まっていないといけない。そこで、設計という行為がはいりました。ここで、
つじつまを合わせるわけです。
でも、JQueryがあると、画面を先に作っちゃっても、いいわけです。
IDとか場合によってはクラスとかを、各部品に振っておけば、
$(#ID名).で、その部品を指定できるから、
画面作成後にやおらJQueryをつかって部品を指定し、その中の関数を
書けばよい。たとえばボタン1というIDのボタンがあったら、とりあえず、
画面作成時には、IDだけ振っておいて、必要なときに、JQueryで、
$(#ボタン1).click(関数)
とすれば、やりたい処理は後からかける。
また、データベースも直接アクセスするのでなくて、JSON経由で行うようにし、
それだけでなく、処理全般をJSON形式のRESTにして、それを呼び出すようにすれば、
(これってSOA?)
必要なときにサービスを作って、(REST、JSON形式で)
それを必要なときにJQueryでサービスをカフェテリア形式で?
とってきて、盛りあえわせればよい
ってことで、後から挿入する考え方ですむ。アスペクト指向っぽく。
前もって設計するのでなく、後から必要に応じて挿入するというのは、
パラダイムシフトかもしれない。
というのも、
画面をプログラムする際には、
どのような関数を呼び出すかが決まっていないと、呼び出せないし、
画面の出力をしたければ、データ表示方法がきまってるわけで、
そのためには、DBからどのデータを取ってきて、どう処理するか
きまってないといけない。
つまり、画面をプログラミングする前に、処理やDBをどうするか、ある程度
決まっていないといけない。そこで、設計という行為がはいりました。ここで、
つじつまを合わせるわけです。
でも、JQueryがあると、画面を先に作っちゃっても、いいわけです。
IDとか場合によってはクラスとかを、各部品に振っておけば、
$(#ID名).で、その部品を指定できるから、
画面作成後にやおらJQueryをつかって部品を指定し、その中の関数を
書けばよい。たとえばボタン1というIDのボタンがあったら、とりあえず、
画面作成時には、IDだけ振っておいて、必要なときに、JQueryで、
$(#ボタン1).click(関数)
とすれば、やりたい処理は後からかける。
また、データベースも直接アクセスするのでなくて、JSON経由で行うようにし、
それだけでなく、処理全般をJSON形式のRESTにして、それを呼び出すようにすれば、
(これってSOA?)
必要なときにサービスを作って、(REST、JSON形式で)
それを必要なときにJQueryでサービスをカフェテリア形式で?
とってきて、盛りあえわせればよい
ってことで、後から挿入する考え方ですむ。アスペクト指向っぽく。
前もって設計するのでなく、後から必要に応じて挿入するというのは、
パラダイムシフトかもしれない。