- - PR -
プロジェクト分割単位
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-04-01 16:26
システム規模が大きい場合は、細かく分割できた方が
分割して開発が行えると言うメリットがあると思います。 しかも各画面間に直接の関係が無いとなれば、 分割して同時開発と言うのもやりやすいでしょうし。 昨今のハードウエアを対象に考えるのであれば、 よほど冗長なつくりになっていない限りはそこまでパフォーマンスに 影響するとは思えないです。 どちらかと言うとメンテナンス性とか開発効率とかそっちの影響が 大きいのではないかと思います。 DLLを細かく分けると必要最小限の入れ替えで機能を変更したり出来そうですが、 数が多いと管理が面倒になると思います。 通常は形態管理システムを使うでしょうけれど、 あまりにも多いと人為的なミスが発生する可能性が増えると思います。 この辺はトレードオフになると思うのでモジュール分割は必要最小限と言うのが 良いのではないかと私は考えています。 | ||||||||||||
|
投稿日時: 2008-04-01 22:16
私はたまに使う手法として
人ごとにDLL化するんです。 すると物理的に割れる事によって 他人同士、I/Fを明らかにしなければならない と言う重大な事に気づくのです。 （ホントは逆ですが） あと、スマートクライアントではないですよね（？） Windowsアプリならアセンブリ配置にあまり気にしなくてもよいのでは？ （しいて言えば、Sale.dll, Stock.dll等、名前から機能がわかるぐらいがよいのでは） | ||||||||||||
|
投稿日時: 2008-04-02 00:03
私ならですが、マスタ・在庫・売上をDLLにします。 それ以外にシステム共通系としてDLLを１つと起動用のexeを用意します。なので5分割でしょうか。 [追記] 肝心なこと書き忘れました。 他の方も記載していますが、アセンブリの数が多くなりすぎると管理が面倒になるというのがあります。 あとWindowsFormでは、いくつかのDLLに分割した場合でも、configファイルとしては、xxx.exe.configの1つとなります。そのためDLL側は考慮しなければならないケースがあります。すべてexeなら問題にはならないと思いますが。。。 [ メッセージ編集済み 編集者: GENZO 編集日時 2008-04-02 00:13 ] | ||||||||||||
|
投稿日時: 2008-04-02 10:07
GENZO様、indigo-x、ぱてお様 返答ありがとうございます。
やはりdll分割単位もこれといった解はなく、保守・開発性とのトレードオフということですね。皆様の意見を参考にdll分割単位を再考します。 indigo-x様 よろしければスマートクライアントではどのように分割されてるのか参考までに教えていただけないでしょうか？ 私が作成したものは1exeと共通系のdllを1つで2分割としています。 これは単にスマートクライアントではシステム規模がさほど大きくないためという理由だけです。 よろしくお願いいたします。 | ||||||||||||
|
投稿日時: 2008-04-02 11:15
CLR は必要最小限のモジュールをオンデマンドにロードしますから気にすることはないと思います。
開発者はうんざりするどころか喜ぶと思いますよ。 開発者がうんざりするとすれば、各アセンブリに強い関連性がある場合ではないでしょうか? もしくは 「1 人で 100 アセンブリ作れ」 と言われた場合ではないでしょうか? (そんなことはあまりある話ではないですが) 開発者の人数が増えれば増えるだけ喜ばれます。(喜ばれるというよりは不満が減るといった方が正しいかもしれません) 大規模開発で多くの人間が関わる前提だとしたらどうでしょう? すでに意見として挙がっているとおり、アセンブリごとに割った方が考える範囲が狭くなり容易になります。 また問題も発生しにくいですし、問題を早期発見できます。 アセンブリの管理はある程度の数を超えてしまうと大変さに変わりはありません。 どうせ VSS 任せになったりします。
マスタ系、在庫系、売上系で 50 アセンブリです。これらが、大規模開発だった場合は、これに加え 「分散ソリューション」 を使うと思います。 マスタ系、在庫系、売上系で各々ソリューションを作ります。 そうすれば、1 ソリューション 1 ~ 20 アセンブリで管理できるということになります。 システム自体を分けるという発想ですね。 (これでまとめて発注しやすくなりますよw) ひとつのシステムにいくつか業務形態の処理があるようなアプリケーションは、多くの場合は部署 (オペレータ) によって不要なものがあります。 ですので 「分散ソリューション」 というのも開発形態としてはアリでしょう。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||
|
投稿日時: 2008-04-02 11:45
じゃんぬねっと様
上記に関して確認させてください。 たとえば相互に関連のない50個の画面を1dllにしたとして、 オペレータがそのうち1つの画面にアクセスしようとした場合、 その他の49個の画面もロードされるのですよね？ そこに無駄が発生すると感じますが、保守性との兼ね合いで適度に分割されていれば 気にすることはないということでしょうか。 | ||||||||||||
|
投稿日時: 2008-04-02 12:01
いいえ。 ロードされません。 CLR は型を参照しているメンバが呼ばれるまでアセンブリ モジュールをロードしません。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||
|
投稿日時: 2008-04-02 12:14
スマートクライアントでの考慮点はいくつかあると思いますが。
・当然（Web)サービス系とは分離されると思いますが、そうすると クライアント系との共通な部分は別DLLとして実装しなければなりません ・ClickOnceの場合ならVSのプロジェクトプロパティのセキュリティ にてアセンブリ単位にアクセス許可を設定できるようになってます のである程度切り分けが必要です。 ・あと、生々しいSQL文または（ノウハウ的）ビジネスロジックが クライアントに行くのを嫌う場合もあります。（同一アセンブリなら） ・その他見られたくない情報（リソース等）まで行く場合です。（同一アセンブリなら） その他もあると思いますが。。。。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。