- PR -

アセンブリの分割方法について

1|2 次のページへ»
投稿者投稿内容
やじゅ
常連さん
会議室デビュー日: 2008/07/15
投稿数: 28
お住まい・勤務地: 静岡市
投稿日時: 2008-07-15 11:05
業務アプリ開発に関する疑問や不安を共有・解消するための雑談の場
とのことで、VB業務アプリケーション開発研究室 にしました。

VB.NETのアセンブリ分割方法について、お聞きしたいのですが、
みなさんはどのように開発しているのでしょうか？


現在の開発方法
　メニュー画面のみEXE形式、他はDLL形式とします。
　システムで共通で使用するクラスは、共通クラスライブラリ群として
　1DLLとして作成し、各プログラムで参照して使用する。

１画面(機能)１DLLとして作成している。
(受注入力.dll、受注一覧表印刷.dll、受注照会.dll ･･･)　

　ある販売管理システムを作成する場合、各担当に製造を依頼します。
　例
　　受注入力 Ａさん 7人日
　　受注一覧表印刷　　Ｂさん 2人日
　　受注照会　　　　　Ｃさん 3人日
　　発注入力　　　　　Ｄさん 6人日
　　発注一覧表印刷　　Ｂさん 2人日
　　発注照会　　　　　Ｃさん 3人日

　各プログラムのプロジェクトファイルでは、
　UI、BL、DA層でクラス分けしてます。

　例 受注入力
　　JuchuEntry.vbproj
　　frmJuchuEntry.vb
　　frmJuchuEntry.Designer.vb
　　frmJuchuEntry.resx
　BussinessLogic.vb
　DataAccess.vb
　参照
　　共通クラスライブラリ.dll
　

　１画面(機能)１DLLとすると、ファイル数が機能数分、増えてしまいます。
　しかし、受注入力だけ仕様変更があった場合など、受注入力.dllだけ、
　アセンブリを入れ替えれば済むという利点もあります。

　循環参照しない単位で、アセンブリをまとめて(受注.dll、発注.dll)しまえば
　ファイル数は減りますが、受注入力だけ仕様変更があった場合、受注.dllを
　入れ替えることになります。

　それとも完全に層で分けたDLLとしてしまうのがいいのでしょうか？
　UI層.DLL 、BL層.DLL、DA層.DLL


　開発規模や各開発者のレベルなど様々な条件はあるとは思いますが、
　みなさんはどのようにしてアセンブリを分割されているのでしょうか？
さかもと
ぬし
会議室デビュー日: 2004/05/14
投稿数: 586
投稿日時: 2008-07-15 11:29
さかもとと申します。
はじめましてｗ

メインメニューをまずexeで作成で、あとはDLLということで・・・

共通クラスライブラリソリューション
-共通１.project
-共通２.project
-・・・・・・・

ソリューション
共通クラスライブラリを必要に応じて参照
-Main.project exe メインメニュー

-Core.project ビジネスロジックやデータアクセス回りを集約（名前はプロジェクト名とかにしてます）
--BLL
---業務１
---業務２
--DAL

-業務１.project dll 各業務画面 必要数の画面を作成するけどDLLは一つ
単なるUI層
--○○処理画面
--××処理画面

-業務２.project dll 各業務画面　必要数の画面を作成するけどDLLは一つ
単なるUI層
--○○処理画面
--××処理画面

-印刷.project dll 印刷指示などは業務とは別に作成
--業務１用印刷
--業務２用印刷


ある程度業務を大きく括って管理しています。業務で修正がある場合は「業務１　DLL」と「CORE DLL」を配信させています。
Coreに開発が集中するきらいはありますが、今のプロジェクトはこのような感じです。

[ メッセージ編集済み 編集者: さかもと 編集日時 2008-07-15 11:34 ]

[ メッセージ編集済み 編集者: さかもと 編集日時 2008-07-15 11:37 ]

[ メッセージ編集済み 編集者: さかもと 編集日時 2008-07-15 11:40 ]

[ メッセージ編集済み 編集者: さかもと 編集日時 2008-07-15 11:41 ]
やじゅ
常連さん
会議室デビュー日: 2008/07/15
投稿数: 28
お住まい・勤務地: 静岡市
投稿日時: 2008-07-15 12:42
さかもとさん
ここでは、はじめましてｗ

返答ありがとうございます。
さかもとさんの例では、層で分けてＤＬＬにしているということですね。
メニュー.exe、共通クラス.dll、Core.dll、業務１.dll、業務２.dll、印刷.dll

この場合、製造はどのようにして担当割りをしているのでしょうか？

業務１を受注入力としまして、担当のＡさんは、
１ソリューションにして開発するような形式となるのかな

受注入力
１ソリューション
　受注入力UI.vbproj
　受注入力BL.vbproj

あとで、個別の層に分けてアセンブリを作成するような方式ですか？
よねＫＥＮ
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2008-07-15 12:43
引用:

八萬さんの書き込み (2008-07-15 11:05) より:
　循環参照しない単位で、アセンブリをまとめて(受注.dll、発注.dll)しまえば
　ファイル数は減りますが、受注入力だけ仕様変更があった場合、受注.dllを
　入れ替えることになります。


こちらですかね。
私なら適度な規模の業務単位にします。
画面単位は細かすぎると思うからです。

例に挙げられている受注の場合では、受注入力、受注一覧表印刷、受注照会の3つは
関連性が強いと考えられるので、1プロジェクトにします。
ソースコードのバージョン管理さえしっかりしておけば、
1プロジェクトにしていても、3つの画面は別々の担当者が開発することもできますね。

さかもと
ぬし
会議室デビュー日: 2004/05/14
投稿数: 586
投稿日時: 2008-07-15 13:03
さかもとです。

>>業務１を受注入力としまして、担当のＡさんは、
>>１ソリューションにして開発するような形式となるのかな

そうですね。
Coreを一つにまとめている関係で、各担当に全ソリューションを渡し、細かい分担は1機能ずつ（1画面ずつ）とかで分けます。

1機能のUIと1機能のBLなど。

画面回りだけをひたすら作り込むUIのみ担当とかに分けたりもしますｗ

何にせよ大規模プロジェクトというわけではないので、境界線を越えることがしばしばですが・・・。
_________________
------------------------------------------
拝啓、さかもとと申します♪
やじゅ
常連さん
会議室デビュー日: 2008/07/15
投稿数: 28
お住まい・勤務地: 静岡市
投稿日時: 2008-07-15 14:33
よねＫＥＮさん
返答ありがとうございます。

引用:

私なら適度な規模の業務単位にします。
画面単位は細かすぎると思うからです。


やはり、ある程度の規模に分けたほうがいいんですね。

.NETエンタープライズWebアプリケーション開発技術大全〈Vol.4〉では
（以下、書籍から引用）
なぜなら、仮にビジネスロジックをクラスライブラリプロジェクトとして分けた
としても、実際のアプリケーションのビルドやリリース、配置作業は
「業務アプリケーションA」というソリューション単位で行われるためである。
つまり、せっかくアセンブリを分割しても、それらのアセンブリが個々に取り
扱われることがないのである。


レイヤーでプロジェクトを分割するのか業務単位にするのか悩ましいところです。
やじゅ
常連さん
会議室デビュー日: 2008/07/15
投稿数: 28
お住まい・勤務地: 静岡市
投稿日時: 2008-07-15 14:35
さかもとさん、返答ありがとうございます。

引用:

Coreを一つにまとめている関係で、各担当に全ソリューションを渡し、細かい分担は
1機能ずつ（1画面ずつ）とかで分けます。

1機能のUIと1機能のBLなど。

画面回りだけをひたすら作り込むUIのみ担当とかに分けたりもしますｗ


その方法では、画面回りだけをひたすら作り込むUIのみ担当者ってのも
いるのですね、参考になります。
やじゅ
常連さん
会議室デビュー日: 2008/07/15
投稿数: 28
お住まい・勤務地: 静岡市
投稿日時: 2008-07-15 15:17
システム共通(業務共通)で使用する列挙型やConst定義したものは、
単体DLLとして分けているのでしょうか？


今は共通クラスライブラリに含めてしまっているのですが、
仕様変更があった場合に列挙型の中身など増える場合があります、
やはり、別途単一DLLにして分けるのがいいのでかな
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）