- - PR -
VS2005でのプロジェクトの分割単位とソースの配置について
1
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-02-06 10:05
VS2005でのプロジェクトの単位とソースの配置について質問させて頂きます。
この件に関して、私はあまり詳しくない上、周りに詳しい人間がいないため、 一般的にどうすべきかというのがわかりませんので、教えてください。 わかりやすいように、以下の仮シナリオを考えます。 <○○社△△部門開発の××システム> ・名前空間は「○○.△△.××」以下を使用する。 ・Windowsフォームを使用したクライアント・サーバ型アプリケーションとする。 ・業務画面は全部で3画面(それぞれFormA, FormB, FormC)とする。 その他にメニュー画面(FormMenu)がある。 ・いろいろな画面から共通で使用される、ビジネスロジックが組み込まれたクラスが3つ (ClassA, ClassB, ClassC)ある。フォームと使用するクラスの関係は以下の通り。 FormA→ClassA, ClassB FormB→ClassB FormC→ClassA, ClassC (FormMenuではいずれも使用しない) この場合に、一般的にはどういう単位でプロジェクトを分割し、 どういうフォルダ構造でソースを配置するのがよいのでしょうか? 一応、私が考えてみた案としまして、以下の3つがあります。 (☆マークのついているのがスタートアッププロジェクトとします) <案1> 以下の5つのプロジェクトを作成する ・共通クラスプロジェクト(ルート名前空間「○○.△△.××.Common」) ・FormA用プロジェクト(ルート名前空間「○○.△△.××.A」) ・FormB用プロジェクト(ルート名前空間「○○.△△.××.B」) ・FormC用プロジェクト(ルート名前空間「○○.△△.××.C」) ・☆メニュープロジェクト(ルート名前空間「○○.△△.××.Main」) この案では、共通クラスプロジェクトにClassA, ClassB, ClassCの3つのクラスを置きます。 <案2> 以下の2つのプロジェクトを作成する ・共通クラスプロジェクト(ルート名前空間「○○.△△.××.Common」) ・☆画面用プロジェクト(ルート名前空間「○○.△△.××.Main」) この案では、共通クラスプロジェクトにClassA, ClassB, ClassCの3つのクラスを置きます。 また、メニューも画面用プロジェクトに含めます。 <案3> プロジェクトを1つだけ作成する ・☆メインプロジェクト(ルート名前空間「○○.△△.××.Main」) 全てをメインプロジェクト内に配置します。 ただし、フォーム・共通クラスの2つのサブフォルダを作成し、その中に格納します。 それにあわせて、名前空間も変更します。 なお、今回の開発(もう終わりに差し掛かっていますが)では<案1>のスタイルを取っていました。 しかし、リソースやアプリケーション設定の管理等がプロジェクト単位になってしまうため、 システム全体でデザインや設定等を共有したいと思ったときに、 いろいろと不便を感じることが多かったです。 的外れな案ばかりかも知れませんので、よりよい案があればご提示頂ければと思います。 いろいろなご意見・ご指導等、お待ちしています。 | ||||||||
|
投稿日時: 2007-02-06 10:21
Form1, 2, 3 がそれぞれどう言った役割かがわからないのでどうともいえませんが、
僕の場合は大体サブシステム単位で分割します。 _________________ かるあ のメモ と スニペット | ||||||||
|
投稿日時: 2007-02-06 10:52
この "画面" というのは、"メニュー" があることからして 「サブ システム単位」 であると解釈しました。 サブ システム単位であれば、私は [案 1] にします。 時と場合 (データ連携など) によって変わることはありますが、仕事の切り出しがしやすいのでそうしています。 これらを統合するためにソリューションという単位があるので、今のところ特に困ったことはないです。 クラス ライブラリについては、汎用性の高いものはさらに細分化します。 その案件に特化したものであれば、分けないことが多いです。 そういう意味では、メニューをクラス ライブラリ含ませてしまうのもアリでしょう。 (起動のコストや、データの受け渡しが楽という理由もアリ) _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2007-02-06 11:29
かるあさん、じゃんぬねっとさん。
お返事ありがとうございます。 説明不足で、意図が伝わらなかったようです。申し訳ありません。 仮シナリオは、サブシステム分割も考えていない、ごく小さなシステムのつもりで挙げました。 ですから言わば、サブシステム内で、どのように分けたほうがよいかというお話になるかと思います。 FormA, FormB, FormCは本当の業務の1機能(例えば受注入力画面とか)で、 FormMenuはサブシステムのメニューと考えて下さい。 しかしながら、かるあさん、じゃんぬねっとさんのご意見は サブシステム単位でプロジェクトを分割するとのことですので、 言い換えれば1サブシステムに対しては、1プロジェクトということになりますか?(つまり案3) そうだとすれば、そのサブシステム内でのクラスの整理は、サブフォルダを使って行うのでしょうか? 例えばFormAが「受注入力画面」、FormBが「受注検索画面」として、 ClassBが「受注」を表すクラスだとすると、FormAからもFormBからもClassBを使用する形になります。 FormAとかFormBとClassBを同じ階層に置いてしまうと、クラスが多くなるとわかりにくくなると思いますので、 「共通クラス」「画面」のようなフォルダを作って、名前空間も分けたほうがよいと考えたのですが、 そういう考え方で問題ないでしょうか? | ||||||||
|
投稿日時: 2007-02-06 11:41
ファイルの位置、名前空間は別として、そうなるでしょうね。
問題はないですよ。 名前空間の使用方法の違いは、思想の違いでしかありませんから正解というものはありません。 ファイルの位置についても、Java や C# では名前空間 (パッケージ) と同期を取るように配置している方が多いと思いますが、これもプロジェクト内で、ポリシを決めてそれどおりであれば問題にはならないでしょう。 # VB の場合は、IDE から同期されることがないですし...w (C# は作成時に同期する) _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2007-02-06 12:15
じゃんぬねっとさん、ありがとうございます。
はい。もちろん「これが正解」という答えを期待していたわけではありませんが、 ある程度一般的なやり方というのがあるのかなと思い、 皆さんの意見を聞いてみたくてスレッドを立てた次第です。 実際、今回の開発では、どうすればよいかわからなかったので、 業務の1機能ごとに1プロジェクトを作るような構造にしたのですが、 データの受け渡し等でいろいろ苦労させられてしまいました。 これならプロジェクトは1つでよかったのかなぁと、後悔させられましたので…w C#ではなくVBだったのですが、こういう構造にした理由というのは、以下のような理由でした。 (1) 名前空間とフォルダ構造を同期させるのがよいという情報が本に載っていた。 (2) IDEからサブフォルダ内にソースファイルを作ったときに、名前空間が同期されなかった。 つまり、名前空間を同期させるとしたら自分でNamespace〜End Namespaceを書かないといけないわけで、 「それなら面倒なのでプロジェクト分けようか」くらいの気持ちでした。 じゃんぬねっとさんのおっしゃる通り、C#だと同期してくれるんですけどね… でも確かにVBなら、名前空間と無理に同期させる必要がないというのも、 言われてみれば一理あるような気がしてきました。 |
1