つい数年前までは、ネットの情報はPCのブラウザで得る、もしくはガラケーで得るというのが主流でしたが、スマートフォンやタブレットなどのデバイスや各種アプリなどが増えてきて、より手段が多様化しています。
Viewレイヤーは基本的にそれぞれに合わせて開発することになりますが、データストアに近いところのプログラムは変える必要がありません。
技術屋さんにとっては、プログラムの中にSQLを交えて書く（ViewとModelがごっちゃ）などの開発スタイルはずいぶんと前に一蹴されていましたが、現場の印象を申しますと、とにかく簡単に作ってくれという風潮が悪しきプログラミングスタイルを生き残らせていたと思います。
でも、これだけ表現方法が多様化してくると、データストア部分と表現部分のプログラムをしっかりと切り離しておくことは、もはや必須だと思います。
これまでは、フレームワークの中でプログラムを書く場所が異なるという意味で切り離されていましたが、今後は、それにとどまらず、別のプログラム言語でもいいし、別の会社が開発しても良いというところまで切り離す必要があるでしょう。
そうなるともうWebサービス化するしかないですね。
SOAPが出来れば、Viewは何でも来いって感じになりますからね。
データストア → SOAP/REST → 各種Viewプログラミング（言語問わず）
これまで、愛用してきたBlazeDSは、普通のWebサイトとの連携がネックでした。
オープン化されているとはいえ、Adobeの技術だから仕方がありません。
データストア → BlazeDS → Airアプリケーション、スマートフォンアプリケーション（Air）、
（普通のWebサイトと連携しづらいという弱点があります。Flashが万能であればと悔やまれてなりません。ただ、AirはWindows,MacOS,Linux,Android,iPhone等で動きますので、弄り倒しています。）
また、DB2を利用してXMLデータベースを利用する方法も良いなと思っていました（実際にWebサービスは簡単に作れます）が、XMLの扱いがなかなか難しいように思えました。具体的には、XQueryなどの出番になったときに開発ツールがJava程には有用ではないという印象です。
XML-DB → SOAP/REST → 各種Viewプログラミング（言語問わず）
ということで、Apache CXFをいじっています。
そんな中でみつけた、Eclipseのプラグイン。
まだ、確かめていませんが、便利（そう）なプラグインがあるものです。
あ、あとデータストア部はORマッピングせず、オブジェクトデータベースを利用するほうがRADできると思っています。
世の中的にどうなのかはわかりません。
0 件のコメント:
コメントを投稿