none
ファイル構成について、どのように構成するとビルド時間、作成効率が良くなるでしょうか? RRS feed

  • 質問

  • 下記の環境・構成だとビルドに時間がかかると先ほど質問して回答をいただきました。
    http://social.msdn.microsoft.com/Forums/ja-JP/aspnetja/thread/69075454-b0e7-4cdd-a9db-0d1fdb728e08

    「リビルド」:3分30秒
    共通ライブラリ部分[App_Code]内のファイルを変更後の「WEBサイトのビルド」:3分30秒
    画面単位の修正後の「WEBサイトのビルド」:これは数秒で帰ってきます。


    --------------------------------------------------
    ★質問 ファイル構成について、どのように構成するとビルド時間、作成効率が良くなるでしょうか?
    --------------------------------------------------
    作業効率を上げるためには、このような作りはおかしいのでしょうか?

    改修業務で、このシステムが回ってきたのですが、今から約180画面分追加することになります。
    (単純に同じような画面なのですが、画面内の項目数と画面数がありまして)
    種別ごとにソリューション細かく分割するような構成に、作り直すべきなのでしょうか。

    ・登録用 Aパターン(30画面)
    ・登録用 Bパターン(30画面)
    ・登録用 Cパターン(30画面)
    ・閲覧用 Aパターン(30画面)
    ・閲覧用 Bパターン(30画面)
    ・閲覧用 Cパターン(30画面)


    このようなファイル構成だとこうした方がいいよとか、
    こういう風にしていますとか、教えていただければと思います。

    なにかがおかしいからだと思うのですがヒントでもよいのでお願いします。

    どうぞよろしくお願いいたします。

     

    ------------------------------
    ■マシン環境
    ------------------------------
    OS:XP Pro(32ビット)
    Visual Studio 2005
    CPU:Xeon E5540 2.53GHz
    メモリ:4GB
    HDD: Cドライブ80GB(空き35GB)
    HDD: Dドライブ200GB(空き120GB)
    ネットワーク上のvisualsourcesafeのDBを使用


    ------------------------------
    ■ファイル構成
    ------------------------------
    D:\に格納
    [ソリューション]
        TEST.sln
        TEST.suo
       
        [CustomControl](プロジェクト)
            CustomControl.vbproj
            GridView.vb
            Label.vb
            TextBox.vb
            [bin]
            [My Project]
            [obj]
        [TEST](WEBサイト)
            [App_Code]共通ライブラリ
                AAA.vb
                BBB.vb
            [App_Data]
                Message.xml
            [Bin]
                CustomControl.dll
                CustomControl.pdb
                CustomControl.xml
            [com]
                9画面
                com1.aspx
                com1.aspx.vb
                ~
                com9.aspx
                com9.aspx.vb
            [aaa]
                9画面
                aaa1.aspx
                aaa1.aspx.vb
                ~
                aaa9.aspx
                aaa9.aspx.vb
            [bbb]
                34画面
                bbb1.aspx
                bbb1.aspx.vb
                ~
                bbb34.aspx
                bbb34.aspx.vb
            [ccc]
                65画面
                ccc1.aspx
                ccc1.aspx.vb
                ~
                ccc65.aspx
                ccc65.aspx.vb
            [img]
                画像21ファイル
            Default.aspx
            Default.aspx.vb
            MasterPage.master
            MasterPage.master.vb
            PrintMasterPage.master
            PrintMasterPage.master.vb
            StyleSheet.css
            web.config

    2009年12月17日 2:54

回答

  • 似たような画面を180画面追加という時点で、何かおかしいぞと考えたいところです。

    180画面というのは表示上の要求仕様であって、aspxファイルの数ではないのではないか、異なる画面であっても一本のaspxにクエリパラメーターを与えることで処理を分けられないか、一本のaspxにならなくてもユーザーコントロールで処理をまとめられないか、などまず考えたいところです。

    私自身は、似たような画面が2画面登場した時点でそう考えていまいます。
    それは過剰かもしれませんが。
    • 回答としてマーク H.S.3 2009年12月18日 5:32
    2009年12月17日 5:23
  • 共通コードをApp_Codeではなくライブラリに入れてみるとか。

    このフォーラムとしては客先の事情はあまり関係ないですからねぇ…。
    最近だとページ遷移せずに、JavaScriptでコンテンツを書き換えるAjaxとかあります。
    たとえばこのフォーラム自身も、返信・投稿をしてもアドレスは変わりません。
    この構造をとると.aspxの数が激減すると思います。
    • 回答としてマーク H.S.3 2009年12月18日 5:32
    2009年12月17日 13:28
  • 佐祐理さんのクラスライブラリ化するのが、一番手っ取り早く問題解決できる方法ですね。
    そのうえで、ソリューションをもっと細かい単位に分割して、並行ビルドするっていう手が対処療法としてはよさそうです。

    気になったのは、既にこれだけのaspxファイルがあるのに、共通部分を度々?変更する必要があるという事がひっかかります。
    本当に共有すべきコードだけで構成されているのか?
    コードで実現せずに済む実装が考えられないのか?
    を検討してみることも有効かもしれません。

    K.Oumi
    • 回答としてマーク H.S.3 2009年12月18日 5:32
    2009年12月18日 1:13

すべての返信

  • 似たような画面を180画面追加という時点で、何かおかしいぞと考えたいところです。

    180画面というのは表示上の要求仕様であって、aspxファイルの数ではないのではないか、異なる画面であっても一本のaspxにクエリパラメーターを与えることで処理を分けられないか、一本のaspxにならなくてもユーザーコントロールで処理をまとめられないか、などまず考えたいところです。

    私自身は、似たような画面が2画面登場した時点でそう考えていまいます。
    それは過剰かもしれませんが。
    • 回答としてマーク H.S.3 2009年12月18日 5:32
    2009年12月17日 5:23
  • miuras_net様

    ご回答ありがとうございます。

    やはりそもそもの作りが悪いと、いうことですね。


    現在は種類として約15種類あり、追加で約30種類を追加という内容で
    閲覧編・更新編が2種類・一覧編という作りなのですが、

    他社より回ってきた段階で、力業で単純にそれぞれ15種類ずつ作ってあった状態です。
    項目は種類ごとにちょっとずつ違っていて、デザイン画面はそれぞれ用意し、共通部分の登録・値セットは、「App_Code」フォルダにまとめてありました。

    実はほかに、大きく「一般用」「管理用」にも分かれているので、さらに倍といったところです。

    試しに1種類追加しているところなんですが、難しくはないのですが、単純に時間がかかっていまして
    どうにかならないのかと考えていたとところでして。


    考えたのは
    始めの切り分けとして、元々の構成が悪いのか、うちの環境が悪いのかの切り分けからと思っていました。
    これは、ファイル数量に比例して遅くなる3分30秒かかる。うちの環境が悪いのではない。時間は妥当。

    ----------------------
    ■対応
    ----------------------

    1.
    現状では、ファイル構成から作り直すわけにもいかないので、
    ソリューションを分割し、「閲覧編・更新編が2種類・一覧編」などに分けるのがよいのでしょうか?

    2.
    それとも根本対応しないことには解決しないのかとも考えています。
    トータル費用・期間を考えるといっそのこと作り直した方がよいのではないか、
    ただ客先に作り直さないといけない説明が難しいような、元々の構成が悪いでは角が立ちますし
    うまい説明がないものかと。
    愚痴っぽくなり申し訳ありません。


    見ないことには何ともいいようの無いことだとは思うのですが、客観的にどう思われますでしょうか?

    2009年12月17日 7:39
  • 共通コードをApp_Codeではなくライブラリに入れてみるとか。

    このフォーラムとしては客先の事情はあまり関係ないですからねぇ…。
    最近だとページ遷移せずに、JavaScriptでコンテンツを書き換えるAjaxとかあります。
    たとえばこのフォーラム自身も、返信・投稿をしてもアドレスは変わりません。
    この構造をとると.aspxの数が激減すると思います。
    • 回答としてマーク H.S.3 2009年12月18日 5:32
    2009年12月17日 13:28
  • 佐祐理さんのクラスライブラリ化するのが、一番手っ取り早く問題解決できる方法ですね。
    そのうえで、ソリューションをもっと細かい単位に分割して、並行ビルドするっていう手が対処療法としてはよさそうです。

    気になったのは、既にこれだけのaspxファイルがあるのに、共通部分を度々?変更する必要があるという事がひっかかります。
    本当に共有すべきコードだけで構成されているのか?
    コードで実現せずに済む実装が考えられないのか?
    を検討してみることも有効かもしれません。

    K.Oumi
    • 回答としてマーク H.S.3 2009年12月18日 5:32
    2009年12月18日 1:13

  • 佐祐理様
    K.Oumi様

    ご回答ありがとうございます。

    対処療法で対応しようと思います。


    1.共通コードをApp_Codeではなくクラスライブラリ[CustomControl]に入れる。

    2.共通コードを細分化する。
      現在は、共通コードの中に、DB取り出し、DB書き出し、変換等、ごちゃ混ぜに入っているので分類しファイルを分ける
      K.Oumi様がおっしゃられたとおりで、
      共通すべきコードでないものがたくさん入っていました。

    3.ソリューションを分割する。


    この内容で検討しようと思います。
    皆様ありがとうございました。

    2009年12月18日 5:31