- PR -

VB2005らしい設計とは?

投稿者投稿内容
檜山
会議室デビュー日: 2006/04/13
投稿数: 15
投稿日時: 2006-04-15 02:08
今までVB6でクライアント/サーバーシステム(以降CSS)を開発していたのですが
そろそろVB2005に移行する予定でいます。
サーバー側は基本的にSQL Serverを配置してあるだけなので開発は主に
そこにアクセスするクライアント側アプリケーションになるのですが
今までのVB6ではだいたい以下のようなディレクトリ・ファイル構成で開発していました。
システム名ディレクトリ
 ├共通モジュール類ディレクトリ
 │ 共通モジュール.bas、共通フォーム.frm、…
 ├アプリケーション1ディレクトリ
 │ アプリケーション1.vbp、アプリケーション1.frm、…
 ├アプリケーション2ディレクトリ
 │ アプリケーション2.vbp、アプリケーション2.frm、…
 :
CSSということで各クライアント側アプリケーションでは
接続先サーバー名や接続ユーザー名、パスワード等(以降システム設定)が必要なので
これらがiniファイルやレジストリに保存してあるという前提で
共通モジュール内にてそれらをPublic変数として宣言したり
それらを読み取るための関数などを記述しておき、
各アプリケーション開発者が不用意に編集することのないよう
「読み取り専用」にしてプロジェクトに追加して利用してもらう方法をとっていました。

そこで既にVB2005で開発をしている方々にお聞きしたいのですが…

  1. VB2005で上記のような構造をそのまま実現させるなら
    「モジュール」として準備しておいて
    各プロジェクトでは「リンクとして追加」するのが同様の構成になると思いますが
    過去ログなどを検索した感じだと一般的(?)には
    やはりクラスライブラリとして作ったりして各プロジェクトで参照するものですか?
  2. 上記システム設定と読み書きのメソッドをクラスで持つとしたら
    iniファイルやレジストリなどに保存しておくよりも
    xmlとしてシリアライズ操作するのがVB2005的なのかな?と思ったのですが
    みなさんならどうしていますか?
  3. 「ソリューション」という単位はVB6のプロジェクトグループ(vbg)に
    近いものかな?くらいの印象しかなく、
    大抵アプリケーションの数がけっこうあることなどから
    プロジェクトグループもほとんど使ったことがありません。
    せいぜい一括コンパイルしたいときに便利かな?という程度でしたし
    1アプリケーション対1開発者といった感じで開発しているので
    各々はvbpファイルのダブルクリックで着手、という感じでした。
    VB6ではプロジェクトエクスプローラだったのが
    VB2005ではソリューションエクスプローラになっていることなどから
    もはや基本がソリューション単位のような印象を受けたのですが
    システム全体の開発管理者が始めにソリューションとして
    上記のようなディレクトリ構成を設計し、
    各開発者は「ソリューションのディレクトリを作成」チェックを外して
    それぞれのプロジェクトを保存してもらうような認識で問題ないでしょうか?

以上、「一般的にはどうなのか?」という
けっこう曖昧な質問だとは思いますが色々ご意見をいただければ幸いです。
まどか
ぬし
会議室デビュー日: 2005/09/06
投稿数: 372
お住まい・勤務地: ますのすし管区
投稿日時: 2006-04-15 03:10
#実際に仕事としては経験が無かったりして。。。(汗

文章から察すると、
「オブジェクト指向ではどうなるのか」では無く
「2005ではどうなるのか」というツール主体の質問になっているので
オブジェクト指向について理解が浅いのかなと思いました。
つまり、VB6の仕組みと実装形態がこうだから開発環境がこうなるという段階を踏むのに対して
いったいどうなるんだという漠然とした質問だと感じました。

まずはオブジェクト指向、そしてそれを基にしたツール(2005)およびその構成単位(クラス、ソリューションなど)
について理解されたらと思います。

#余計なお世話だったら失礼。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-04-15 09:17
引用:

檜山さんの書き込み (2006-04-15 02:08) より:

VB2005で上記のような構造をそのまま実現させるなら
「モジュール」として準備しておいて各プロジェクトでは
「リンクとして追加」するのが同様の構成になると思いますが
過去ログなどを検索した感じだと一般的(?)には
やはりクラスライブラリとして作ったりして各プロジェクトで参照するものですか?


はい、できれば「リンク ファイル」はやめましょう。
アセンブリがそれだけ 'ムダに' 太ります。

引用:

上記システム設定と読み書きのメソッドをクラスで持つとしたら
iniファイルやレジストリなどに保存しておくよりも
xmlとしてシリアライズ操作するのがVB2005的なのかな?と思ったのですが
みなさんならどうしていますか?


はい、INI ファイルではなく、XML ファイルを使うべきです。
シリアライズ / デシリアライズはその際の手段のひとつです。

引用:

もはや基本がソリューション単位のような印象を受けたのですが
システム全体の開発管理者が始めにソリューションとして
上記のようなディレクトリ構成を設計し、
各開発者は「ソリューションのディレクトリを作成」チェックを外して
それぞれのプロジェクトを保存してもらうような認識で問題ないでしょうか?


各プログラマの作業専用のソリューションを作るのは結構ですよ。
クラス ライブラリ (以前の共通モジュールにあたる) + 個々のプロジェクト (1 つだけ) の構成です。

セットアップの際には、すべてのプロジェクトを追加した '別の' ソリューションを使えば良いです。
ソリューション ファイルは 1 つにしなくてはならない、わけではないですし、
あるプロジェクトが他のソリューションで重複することが許されないわけでもありません。

引用:

以上、「一般的にはどうなのか?」という
けっこう曖昧な質問だとは思いますが色々ご意見をいただければ幸いです。


ですので、私もざっくりとしか回答しませんでしたが、こんな感じでご納得できますでしょうか?

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
R・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-04-15 09:23
引用:

檜山さんの書き込み (2006-04-15 02:08) より:

今までVB6でクライアント/サーバーシステム(以降CSS)を開発していたのですが
そろそろVB2005に移行する予定でいます。



僕の場合と非常に似ています。僕の場合は、その後、C#へ以降した訳ですが。

共通で使用するものは、別にプロジェクト(ディレクトリーも)を作って、主体となる
開発アプリケーションのソリューションに含めてやると良いです。
VB6では、共通して使う関数などをモジュールでまとめることが多いですが、僕の場合
は、基本的にクラスの下に静的なメソッドを作って提供する形をとっています。
檜山
会議室デビュー日: 2006/04/13
投稿数: 15
投稿日時: 2006-04-15 18:14
引用:

まどかさんの書き込み (2006-04-15 03:10) より:

「オブジェクト指向ではどうなるのか」では無く
「2005ではどうなるのか」というツール主体の質問になっているので
オブジェクト指向について理解が浅いのかなと思いました。



仕事ではVB6→VB2005と移行していく予定ですが
私個人はVC++開発経験があるのでクラス、ポリモーフィズム、継承といった
オブジェクト指向の基本概念はだいたい理解できているつもりです…多分
なので逆にオブジェクト指向ではこうだろう、と思っていても
VB2005では未だに「モジュール」などがサポートされているようだったので
敢えて「VB2005ならどうするか?」という形でご意見を求めてみました。

なのでじゃんぬねっとさんのご意見はとても参考になりました。
#ホームページの方もよく拝見しています
現在の共通モジュールは実際にはあまり整理されていないものが多く、
共通部分の抽出の甘さや汎用性の乏しさを感じているのですが
逆にそのせいで共通モジュールに含まれるボリュームが少ないので
アセンブリが太るという意識があまりありませんでした。
今後はもっとその辺を整理してソースレベルでの共有ではなく
やはりアセンブリレベルでの共有を目指した方がよさそうですね。

INIファイルやレジストリの操作に関してもAPI関数だと
仮に該当ファイルや項目キーが存在しなかったとしても
変数にデフォルト値を取得できるような作りになっていたと思いますが
実際にはシステム設定が見つからないこと自体が「例外」なので
XML(クラス)のシリアライズ操作だとその辺をはっきりさせられそうだと思っていました。
デフォルト値を「あり」にしたいのであればコンストラクタでやればいいことですし
あとはその辺を今のVB開発者達にどう納得させていくか、ですね
今までは気にしなくてもよかったことに潜んでいる危険性というか甘さというか…。

引用:

じゃんぬねっとさんの書き込み (2006-04-15 09:17) より:

各プログラマの作業専用のソリューションを作るのは結構ですよ。
クラス ライブラリ (以前の共通モジュールにあたる) + 個々のプロジェクト (1 つだけ) の構成です。

セットアップの際には、すべてのプロジェクトを追加した '別の' ソリューションを使えば良いです。
ソリューション ファイルは 1 つにしなくてはならない、わけではないですし、
あるプロジェクトが他のソリューションで重複することが許されないわけでもありません。


引用:

R・田中一郎さんの書き込み (2006-04-15 09:23) より:

共通で使用するものは、別にプロジェクト(ディレクトリーも)を作って、主体となる
開発アプリケーションのソリューションに含めてやると良いです。
VB6では、共通して使う関数などをモジュールでまとめることが多いですが、僕の場合
は、基本的にクラスの下に静的なメソッドを作って提供する形をとっています。



いちいちソリューションが作られることに違和感を感じていたのですが
今までのプロジェクトグループ同様、ソリューションとしてまとめるべきものはまとめるようにして
各プログラマーが個別に作る(作ってしまう)ソリューションは
あまり気にしなくてもよい、ということですね?

既存のVB6開発者は「クラス」「インスタンス」にだいぶ抵抗があると思いますし
システム設定読み込み/書き込みなどの複数インスタンスが不要なものに関しては
私も静的メソッドで提供するような設計にしていくつもりです。

VB2005はオブジェクト指向になった、と聞いていたのに
前述の通り未だにVB6っぽい作りもできなくもないような感じだったので
色々と迷いがあったのですがこれで少し自信が持てました。
ご回答ありがとうございました。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-04-15 19:00
引用:

檜山さんの書き込み (2006-04-15 18:14) より:

VB2005では未だに「モジュール」などがサポートされているようだったので
敢えて「VB2005ならどうするか?」という形でご意見を求めてみました。


標準モジュールは、静的メンバしか含むことができないクラスだと考えれば良いですが、
(実体は StandardModule 属性が付与されたクラスに過ぎませんから)
クラス名に当たるモジュール名が省略できてしまうのがダメなところなんですよね。orz
そのため、私は使っていません。

引用:

VB2005はオブジェクト指向になった、と聞いていたのに
前述の通り未だにVB6っぽい作りもできなくもないような感じだったので
色々と迷いがあったのですがこれで少し自信が持てました。


VB2005 というより VB6 もオブジェクト指向で組むことができます。
(極論を言えば、アクセス修飾子があれば OOP できるのです)
逆に無視することもできますが、正直お勧めできません。

VB6 の「クラス モジュール」と比べて '遥かに' 強力になった、
VB200x の「クラス」を是非、ご堪能して頂きたいです。

手探りで開発するのであればこそ、プロトタイプなプログラムの作成は必須だと思います。
檜山さんが担当されるかどうかは判りませんが、
少しここで工数をかけた方が、後々工数を減らすことに繋がるように思えます。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
檜山
会議室デビュー日: 2006/04/13
投稿数: 15
投稿日時: 2006-04-15 20:31
引用:

じゃんぬねっとさんの書き込み (2006-04-15 19:00) より:

VB2005 というより VB6 もオブジェクト指向で組むことができます。
(極論を言えば、アクセス修飾子があれば OOP できるのです)
逆に無視することもできますが、正直お勧めできません。

手探りで開発するのであればこそ、プロトタイプなプログラムの作成は必須だと思います。
檜山さんが担当されるかどうかは判りませんが、
少しここで工数をかけた方が、後々工数を減らすことに繋がるように思えます。



新しい開発言語には産まれた理由というか目指した思想みたいなのがあると思うのですが
VBはどうも既存の開発者に優しい作りを目指しているようで
現場レベルの動けばいい、という考えを改めさせるきっかけが弱いというか…。
なのでOOPという流れがあっても
言語レベルで今までと同じような作りでも通るようになっているせいで
今後はこうしていきましょう、と主張しづらいんですよね。
VB2005への移行がそのきっかけとなるように私自身がもっと理解を深めて
大きな視野で開発工数が減らせるように構築していきたいと思っています。
# 皆さんのところではVB2005への移行はうまくいっている/うまくいったんでしょうか…?
# 結局、今までと同じような設計になったりしていませんか?
まどか
ぬし
会議室デビュー日: 2005/09/06
投稿数: 372
お住まい・勤務地: ますのすし管区
投稿日時: 2006-04-16 00:25
引用:

言語レベルで今までと同じような作りでも通るようになっているせいで
今後はこうしていきましょう、と主張しづらいんですよね。
VB2005への移行がそのきっかけとなるように私自身がもっと理解を深めて
大きな視野で開発工数が減らせるように構築していきたいと思っています。
# 皆さんのところではVB2005への移行はうまくいっている/うまくいったんでしょうか…?
# 結局、今までと同じような設計になったりしていませんか?


実はある大きなパッケージシステムに携わってきました。
.NETがこの世に登場したくらいでそのプロジェクトから離れたのですが、
先日チラッと横目で隣の人のPCに表示されているソース(.NET版)を見ることがありました。
単にアップグレードしただけとは聞いていましたが、大きなもので1000バイト超のテーブル(ユーザー定義型)が
単にStructureキーワードに変化しているだけでした。。。#無知とは恐ろしいと思いました。
このように間違いといっても過言ではない結果になってはいけないと思います。
まずは.NETでの形を覚えた上で見えてくるものがあるのではないでしょうか。

「悩めるVB6プログラマのスレ」
http://vsug.jp/tabid/63/forumid/44/postid/566/view/topic/Default.aspx

スキルアップ/キャリアアップ(JOB@IT)