- - PR -
VS.NETで相互にWindows.Formを参照
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-12-08 16:18
いろいろなご意見ありがとうございます。
架空兎さんへ。 >互いに結びつきが強いクラスはやはり同じプロジェクトにまとめた方が >いいのではないでしょうか？ 結びつきが強いとういのは、やはりここでは 画面遷移において結びつきが強い。という事ですよね。 Jittaさんへ。 >私ならば、まず、画面遷移図を描きます。この中で、 >「＊_2」から次の画面が出ていないなら、これらをまとめて１つの >「参照されるプロジェクト」とします。「プロジェクト」を、 >「機能面」ではなく、「行動面」から作ります。 やはりそうですか。 ちなみに、私の例では、機能的に結びつきが強いものでプロジェクトを構成しました。 なぜなら、 実際の開発において、プロジェクトという集合単位は アプリケーションの構成要素ではなく、開発においての作業単位でしか ないと考えていました。 仮にVS.NETを使用しないで開発した場合（それが現実的かどうかは置いておいて。） Projectという単位は出てこないですよね。 出てくるのは例えば、 ・名前空間 ・アセンブリ ・モジュール などですよね。 だから、大雑把に言うと、 「VS.NETでのプロジェクトの単位は開発においての効率を中心に考慮すれば良い。」 と思っていたわけです。 Jittaさんが言うように、作成した画面遷移図を見て、 プロジェクトの集合を分けるというような作業は 開発作業の為の設計をするような気がして、どうもしっくりきません。 参照がdll参照である以上、仕方ない行程なのでしょうか？ どうも、頭のシフトチェンジがうまくいきません。 さらに皆さんのVS.NETのプロジェクトについての考え方又は プロジェクトとはこういう物だ！というような意見があれば 聞かせて頂きたいと思っています。 よろしくお願いします。 [ メッセージ編集済み 編集者: toppo 編集日時 2003-12-08 16:34 ] | ||||||||||||
|
投稿日時: 2003-12-08 17:39
そうは思いません。私は、システムエンジニアの仕事は「開発者と顧客とのコミュニケーション」と考えます。そして、「開発者」も「顧客」も、「今」から「未来」にわたって複数存在します。それら複数の「人々」とのコミュニケーションです。「今」おらず、「未来」に存在する「人」とコミュニケーションをするためには、ドキュメントが必要です。人の記憶はとてもいい加減だからです。 長い前ふりですが、画面遷移図も、そういったコミュニケーションのためのドキュメントと考えます。開発者の「作りやすさ」と、顧客の「使いやすさ」をトレードするために、双方のコミュニケーションのために必要な資料です。 つまり、経験なんです。過去に「メニュー画面→検索画面→個別画面」と遷移し、個別画面からは「メニュー画面」にしか戻れないアプリを作ったことがあります。開発者としては、「検索画面」で設定したことを覚えておかなくて良いため（あのころは何も知らなかったのよぉ）とても楽だったのですが、顧客にはとても使いづらいものです。仕様書には記述されていたのですが、図はなかったため、顧客には「そういう仕様である」ことがわからなかったのです。そのほか、途中で顧客側の担当者が替わり、顧客の側でコミュニケーションがとれていなかったこともありますが（先の担当者は、端末の頃の仕様のままでよい、と思っていた）。 結局、翌年に改修が入ったのですが、図があれば、新しい担当者の方が気が付いて製造時に変更ができたでしょう。改修時にも、図がないためにどこどこの画面にそれらが必要がわからず、開発者も苦労しました。 まぁ、苦労してください。そうすると、「必要な苦労」と「不必要な苦労」が、自ずとわかるようになってきます。 #大学の教授はこれを、「恨みがある」と表現していたっけ ↓↓昨晩から推敲を重ねているのですが、うまく書き表せません。 ↓↓仕事に支障が出そうなので、返答しないかもしれませんが、ご了承ください。 [ メッセージ編集済み 編集者: Jitta 編集日時 2003-12-09 09:32 ] | ||||||||||||
|
投稿日時: 2003-12-08 19:12
スミマセン。誤解を生んだようです。 私が言いたかったのは、画面遷移図の作成行程が無駄だ。 と、言っているのではなく、 どの画面が、どのプロジェクトに属するか。等の 「プロジェクトを切り分ける」という作業にいろいろな考慮が必要な事が 余計だなぁと思っていたという事です。 例えば、前提としてアクセス修飾子にinternalを使用しなかったとします。 そして、アプリケーション仕様がコーディングできる状態になったとします。 （当然この場合、画面遷移図も含めるとします。） 分担、プライオリティ等を決定して、「さぁコーディングするぞぉ」 となった時に、ちょっと待てよ。 VS.NETで開発する訳だけど、プロジェクトはどう 切り分けたら良いんだ？ となる訳です。 ここで以前（もともとこのスレッドを立ち上げた時点）の私の発想は プロジェクトはアセンブリ毎に分ければ良いんじゃないか。 それで、dllが大きくなるようだったら、さらに適度に細かくすれば良い。 と思っていたのです。 ところが、みなさんに意見を頂いて、どうやら 画面遷移図を見て相互参照に気を付けてコンパイルに影響がでないように、 画面遷移を意識してプロジェクトを分けなければいけない(dllが分かれる為)。 と、なった訳です。 そこで、皆さんはdllをどの用に分けているのかなぁと思ったのです。 勝手にプロジェクトを分ける単位 = dllを分ける単位 という前提で話をしてしまったので、 非常に分かりづらかった事をお詫びいたします。 スミマセン。 乱筆・長文 ご容赦下さい。 | ||||||||||||
|
投稿日時: 2003-12-09 09:01
画面遷移というよりはクラスの関係のことです。 私が言いたかったことは、FormA が FormB を必要としていて、また、FormB が FormA を 必要としている、つまり、お互いを必要としているのに別々のプロジェクトになっているのはおかしい、 ということです。 ＃私の表現がちょっと分かりにくかったですね。。。＾＾；
プロジェクト単位＝アセンブリ単位ではないでしょうか？ ＃ VS.NET を使わないで開発したことはないので詳しくは分からないのですが。。。
ある目的を持ったプログラムの集まり、でしょうか？ ＃私も勉強中なのではっきりとは言えないのですが。。。＾＾； 画面もやはり、目的に向かって遷移していく訳ですから、 その遷移の中にある画面は同じプロジェクトにまとめる、というカンジでしょうか？ これを書いている途中でふと閃いたのですが、 プロジェクト A からプロジェクト B（もしくはその逆）を参照するのではなく、 プロジェクト A とプロジェクト B の両方を参照するプロジェクトを作って、 そこで画面の遷移を行わせる、というのはどうでしょうか？ [ メッセージ編集済み 編集者: 架空兎 編集日時 2003-12-09 15:14 ] | ||||||||||||
|
投稿日時: 2003-12-09 10:31
架空兎さん返信ありがとうございます。
また、たとえ話で恐縮ですが 参照系の画面と更新系の画面でProjectを分けたとします。 （この時点でおかしいでしょうか？） ある時、参照系画面から、更新系の画面を呼び出す必要が出てきました。 またある時、更新系画面から、参照系の画面を呼び出す必要が出てきました。 このような場合は、参照系画面と更新系画面を同じプロジェクトにする しかないということでしょうか。
これって、やはり相互参照になってしまうのでは。。 両方を参照するプロジェクトCは A・Bを参照することになり そしてA・BはCを参照することになる。。。 はぁ。。 これはやはり、プロジェクトを分ける指針を打ち立てないと、 毎回、開発時にひともんちゃくありそうです。。 | ||||||||||||
|
投稿日時: 2003-12-09 12:35
私の意見としてはやはりおかしいと思います。 その参照系、更新系の画面の目的を考えてみてください。 それぞれ、ただ参照するだけ、ただ更新するだけが目的の画面ではないはずです。 もっと大きな目的があってそれらの画面が使われるはずだと私は思います。 もし、その画面がいろんな目的で使われるのであれば、それは共通的な部品として扱い、 それらをまとめたプロジェクトを作るといいと思います。
いいえ、プロジェクト C は A と B を参照しますが、 プロジェクト A と B からはプロジェクト C を参照しません。 あと、一つ言い忘れてしまったのですが、恐らく A、B、C、すべてのプロジェクトから参照される 共通のプロジェクトも必要になると思います。 ＃インターフェースなどを定義するため。 プロジェクト C では全ての画面（ダイアログ的な画面は除く）を管理します。 つまり、画面の遷移をすべてプロジェクト C に任せてしまいます。 そうすれば、例え遷移する画面や順番が変わったとしてもプロジェクト A や B に 手を加えることなく、プロジェクト C だけを修正すれば済むと思います。 しかし、それを実現するためにはちょっと工夫（細工？）をしないとできないかも知れません。。。＾＾； ＃今試しに作ろうとしている（＜仕事は？＾＾；）のですが、 ＃ちょっと荒技（裏技？）のようなことをしています。。。 ＃やっていることは、共通のプロジェクトに全ての画面のベースクラス ＃（System.Windows.Forms.Form と FormA などの間に入るクラス）を作ること。 ＃＃うーん、果たしてこんなことをしていいのだろうか・・・ 
[ メッセージ編集済み 編集者: 架空兎 編集日時 2003-12-09 13:20 ] | ||||||||||||
|
投稿日時: 2003-12-09 13:23
ありがとうございます。
そうですね。 やはり、むやみにプロジェクトを分割してはいけない という事ははっきりしました。 私の今回の大きな命題は、 大きなサイズのdllを縮小する為に 単純に適当なところでプロジェクトを分割してよいのか？ （最初の投稿とは随分ニュアンスが違いますが、 この命題解決の為の投稿でしたのでご理解下さい。） ということでした。 答えとしては、否である。（当たり前といえば当たり前なのかも知れません。） 循環参照にならないように適切に分割できる単位でしか プロジェクトを分割する事は出来ない。 （この答え自体に誤解はないですねよね。） 大きなdllになってしまった場合に サイズを小さく分割しようとしても、 必ずしも可能な訳ではなく、場合によっては 設計の段階立ち返ってみる必要があると。
なるほど。 この場合はAからBを呼び出すというより CがA→Bの順で呼び出すという事ですね。 このモデルなら上記の命題がある程度はクリアできそうです。 Cについては無理ですが、A・Bなどのその他のFormについては 適当に分割しても良いことになります。 各フォームで処理のCallingSeaquenceを統一してやれば、 さらに面白いモデルになりますね。 結果を受け取りエラー画面へ遷移するとか。Controllerの役割を 果たしますね。 ありがとうございます。 すっきりしました。 
試しに作って頂いているとは。
恐縮です。 私も試しにスマートクライアントの画面制御アーキテクチャの 構築という事でそれなりのモデルを作ってみます。 既により良いモデルはあるのかも知れないですが、 かなり有意義な作業になりそうです。 ありがとうございます。 追記---
このような構成は独自のBaseFormクラスとして私も 実装していますよ。 
私は問題なく良い構成だと思います。 ではでは。 | ||||||||||||
|
投稿日時: 2003-12-09 13:39
今やっているプロジェクトで、データベース、文書管理システム、ソース管理システムをそれぞれ複数のパッケージソフトを利用可能にしているので、近い処理をしていると思うのですが。。。。
どうも、うまく言葉にできません。そうですね、参照系、更新系ということですが、 参照系 ←表示させる← コントロール →表示させる→ 更新系 →戻る → ←戻る ← のようにします。参照系（更新系）から更新系（参照系）を表示する際は、プログラムスレッドは次のように流れます。 コントロール→参照系（戻り値：更新系表示）→コントロール→更新系 コントロール→更新系（戻り値：参照系表示）→コントロール→参照系 こうすると、遷移は更新系←→参照系相互ですが、縁の下の力持ち、コントロール君から更新系か、参照系を表示するため、コントロールは更新系、参照系共に「参照」しますが、画面の方はコントロールを参照しません。 #っつうことで、 #「A、B、C、すべてのプロジェクトから参照される共通のプロジェクト」 #は必要ないです＞架空兎さん #と、ここで架空兎さんのハンドルをコピーするためにスクロールして、 #toppoさんの投稿を発見 〜〜〜 大きなサイズのdllを縮小する為に 単純に適当なところでプロジェクトを分割してよいのか？ 答えとしては、否である。 〜〜〜 否、というより、そういう理由で分けようとしたことが「開発作業の為の設計」ではないでしょうか。また、私は「適当」という言葉を使わず、「適切」という言葉を使います。言葉遊びですが、「適当」、本当は「適（かな）う、当たる」なんですけどね。「どうでもいい」というような意味で使われますから。で、「（用途に）適い、当たる」ように設計するならば、もっと慎重に設計するのでは？ | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。