C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[5]: 顧客別オプションのうまいやりかた


(過去ログ 135 を表示中)

[トピック内 8 記事 (1 - 8 表示)]  << 0 >>

■79190 / inTopicNo.1)  顧客別オプションのうまいやりかた
  
□投稿者/ 作業着プログラマ (1回)-(2016/03/14(Mon) 09:30:16)

分類:[雑談] 

皆様、いつもお世話になっております。

私は主に医療向け検査自動機(XYZのロボットハンドが複数付いているようなもの)を
製造しております。
私の担当はマイコンボードのファームウェアと、PCで制御するための
WindowsアプリケーションをC#のWindowsFormで作成しています。
小さい会社ゆえに、営業的にお客様別にオプションてんこ盛り対応が常時だったり、
同じ装置でもWindows側のソフトは要望に対応するために1から作り直したり、
ということを繰り返しています。
人の入れ替えも無くガラパゴスな職場なのと、ほぼ全て自分でやっているために
若さでなんとかやってきましたが、40が見えてきて流石に辛くなってきました。
無駄に自己紹介が長くなってしまいすみません。

相談したい内容ですが、基本のアプリケーションを作成後に
一部機能だけを(例えば、動作やデータは同一だが最後のデータリスト印刷のみ等)
顧客別にオプション対応として作成した場合、今まではVSのプロジェクトを
コピーして作りなおしておりましたが、共通部分の不具合等を対応する場合は
それぞれテスト等が必要になったりして無駄な時間が多いように感じます。

そこで諸先輩方に質問です。
(1)ユーザー別にオプションが存在する
(2)オプションが存在することをユーザーからは見えなくする

上記条件で、少しでも労力を減らせる、もしくはこれがグローバルスタンダードさ!
みたいな素敵なご助力を頂くことは出来ませんでしょうか。

よろしくお願い致します。

※具体的に困っているわけではなく、私の住むガラパゴス島以外の情報を
少しでも聞けたらハッピーと言うだけなので、軽いノリで書き込みしていただけたら幸いです。


引用返信 編集キー/
■79191 / inTopicNo.2)  Re[1]: 顧客別オプションのうまいやりかた
□投稿者/ とっちゃん (336回)-(2016/03/14(Mon) 10:54:31)
No79190 (作業着プログラマ さん) に返信
> (1)ユーザー別にオプションが存在する
> (2)オプションが存在することをユーザーからは見えなくする
>

きちっと設計をしましょう。


と身もふたもないことをまず書いておいて
ざっくりと。。。


基本的には、機能単位などある程度小さなまとまりをDLLにして
それらを組み合わせに応じてつなぎ合わせるというのが
一番使いまわしのきく方法だと思います。

オプション部分については、共通にできるインターフェースを定義できれば
アドオン的に使うこともできます。

コアセットでも、同じようにオプション的な扱いができるのであれば
コアセットそのものもアドオン的に組み合わせることもできます。


このあたりはそのプログラム構成の構造上の問題もあるので
どれが正解というのはありません。

一応。。。個人的にはオプションの組み合わせなら
アドオンタイプがいいんじゃないかなと思います。

ブロックみたいにうまくパーツを切り出せば
既存パーツの組み合わせとほんの少しの専用パーツで
プログラムを用意できるようになります。

引用返信 編集キー/
■79194 / inTopicNo.3)  Re[1]: 顧客別オプションのうまいやりかた
□投稿者/ ぶなっぷ (77回)-(2016/03/14(Mon) 12:44:56)
客ごとに特定機能のOn/Offを行いたいということかな?

私なら、XMLファイルなどに顧客ごとの設定を持たせるかな。
(INIファイルでも、レジストリでも、DBでも、設定を持たせられるなら何でも良い)

以下のような感じで、

<CustomerSetting>
    <Customer Id="1">
        <Name>〇〇会社</Name>
        <PrintDataList>False</PrintDataList>
          :
    </Customer>
    <Customer Id="2">
        <Name>△△会社</Name>
        <PrintDataList>True</PrintDataList>
          :
    </Customer>
    <Customer Id="3">
        <Name>□□会社</Name>
        <PrintDataList>False</PrintDataList>
          :
    </Customer>
</CustomerSetting>

顧客ごとに許可する内容を記述します。
上の例なら、△△会社の<PrintDataList>タグの値がTrueなので、
[データリスト印刷]されるということね。

XMLの値に基づく実際の処理分けは問題ないかと思います。

最悪、客に設定ファイルを勝手にいじられてもいいなら、
そのまま、このXMLファイルごとインストールすればいいし、
勝手にいじられて困るなら、暗号化とかの必要があるかも。

引用返信 編集キー/
■79196 / inTopicNo.4)  Re[2]: 顧客別オプションのうまいやりかた
□投稿者/ 作業着プログラマ (2回)-(2016/03/15(Tue) 08:11:00)
No79191 (とっちゃん さん) に返信
> ■No79190 (作業着プログラマ さん) に返信
>>(1)ユーザー別にオプションが存在する
>>(2)オプションが存在することをユーザーからは見えなくする
>>
>
> きちっと設計をしましょう。

し、、、精進します・・・・


>
>
> と身もふたもないことをまず書いておいて
> ざっくりと。。。
>
>
> 基本的には、機能単位などある程度小さなまとまりをDLLにして
> それらを組み合わせに応じてつなぎ合わせるというのが
> 一番使いまわしのきく方法だと思います。
>
> オプション部分については、共通にできるインターフェースを定義できれば
> アドオン的に使うこともできます。
>
> コアセットでも、同じようにオプション的な扱いができるのであれば
> コアセットそのものもアドオン的に組み合わせることもできます。
>
>
> このあたりはそのプログラム構成の構造上の問題もあるので
> どれが正解というのはありません。
>
一応DLLで分けて対応を行ったことがあります。
その際にアドオン方式にしたいと思ってはいたのですが、
短納期を言い訳にして設計を怠ったため、実現出来ないまま終わったプロジェクトが
有りました。
結局DLLをユーザー別に手で差し替えたりするため、人為的ミスがあったりして
いらぬ苦労をしたほろ苦い思い出となりました。

> 一応。。。個人的にはオプションの組み合わせなら
> アドオンタイプがいいんじゃないかなと思います。
>
> ブロックみたいにうまくパーツを切り出せば
> 既存パーツの組み合わせとほんの少しの専用パーツで
> プログラムを用意できるようになります。
>

やはり、アドオンタイプは有用ということですね。
一度きっちり設計と勉強を行って、試してみたいと思います。

貴重なご意見ありがとうございました。


引用返信 編集キー/
■79197 / inTopicNo.5)  Re[2]: 顧客別オプションのうまいやりかた
□投稿者/ ?????v???O???} (1回)-(2016/03/15(Tue) 09:03:36)
No79194 (ぶなっぷ さん) に返信
> 客ごとに特定機能のOn/Offを行いたいということかな?
>
> 私なら、XMLファイルなどに顧客ごとの設定を持たせるかな。
> (INIファイルでも、レジストリでも、DBでも、設定を持たせられるなら何でも良い)
>
> 以下のような感じで、
>
> <CustomerSetting>
> <Customer Id="1">
> <Name>〇〇会社</Name>
> <PrintDataList>False</PrintDataList>
> :
> </Customer>
> <Customer Id="2">
> <Name>△△会社</Name>
> <PrintDataList>True</PrintDataList>
> :
> </Customer>
> <Customer Id="3">
> <Name>□□会社</Name>
> <PrintDataList>False</PrintDataList>
> :
> </Customer>
> </CustomerSetting>
>
> 顧客ごとに許可する内容を記述します。
> 上の例なら、△△会社の<PrintDataList>タグの値がTrueなので、
> [データリスト印刷]されるということね。
>
> XMLの値に基づく実際の処理分けは問題ないかと思います。
>
> 最悪、客に設定ファイルを勝手にいじられてもいいなら、
> そのまま、このXMLファイルごとインストールすればいいし、
> 勝手にいじられて困るなら、暗号化とかの必要があるかも。
>
XMLでの設定ファイルは使用していますが、顧客から見えてしまうために
個別オプションを含めるのはどうかと思っておりました。
ただ、暗号化する所まで考えが至らなかったので目から鱗でした。
編集自体は専用エディタ等を作製すれば問題無いですよね。

勉強になりました。ありがとうございました。





引用返信 編集キー/
■79198 / inTopicNo.6)  Re[3]: 顧客別オプションのうまいやりかた
□投稿者/ 作業着プログラマ (3回)-(2016/03/15(Tue) 09:13:08)
2016/03/15(Tue) 11:27:30 編集(投稿者)

文字化けしてしまいましたが、ひとつ前は私の書き込みです。

貴重なご意見をいくつか頂けましたが、やはり何でも簡単に解決する魔法のような物はなく、
事前の仕様検討と設計をしっかり行うことが大事で、急がば回れということですね。

頂いたご意見を元に、もう少し勉強をしなおしてみます。
その際、一人では解決できない問題があった場合にはご質問させていただくと思いますが、
よろしくお願い致します。

雑談なので解決というのも変ですが、一旦解決と致します。
※もし、「こういうアプローチもあるぜ!」という物があれば追記して頂けると泣いて喜びます。

追記
この質問をするに至った経緯ですが、ガラパゴス島からの脱出を
目的としてマイクロソフト主催のセミナーに参加した際に、LinqとEntityFrameWorkを
学ぶ事が出来ました。
Linqは私にとってまさに魔法で、昔ながらのforループで10行ぐらいのコードで
シコシコ検索をしていたものが1行に収まった時の感動は忘れられません。
しかも、ループ検索に比べて可読性や保守性も良いおまけ付き。

EntityFrameWorkに至っては、SQL文を一切書かずコンパイルの時点である程度の
エラーも把握出来る聞いた時には、白目を向いて「これが21世紀か・・・」と
しばらく放心してました。
Z80マイコンとモニタデバッガで仕事を始めた頃に比べたら、未来過ぎて目眩がしました。

この体験が忘れられず、まだ見ぬ魔法があったらいいなとの思いから質問させて
頂きました。

この掲示板は様々な方が色々な切り口で書き込みされているので、いつも楽しく
見ています。
今後共お世話になると思いますので、宜しくお願い致します。

解決済み
引用返信 編集キー/
■79551 / inTopicNo.7)  Re[4]: 顧客別オプションのうまいやりかた
□投稿者/ Jitta (192回)-(2016/04/13(Wed) 21:35:47)
機能のプラグイン/アドオン DLL というのは同じ。

C#/VB.NET では、プロジェクトフォルダ外にあるファイルをプロジェクトに追加すると、プロジェクト フォルダにコピーが作られてしまいます。
ですので、DLL に分けて、DLL を参照するというのが一般的かと。

しかし、そうすると、DLL が大量にできてしまいます。
で、顧客毎に「どの DLL だっけ?」とかになってしまう、と。
できるだけ DLL を作りたくないなぁ、と思うことがありました。
そこで発想を逆転。
顧客別プロジェクトに共通機能をプラグインする。
プロジェクト フォルダー外のファイルをプロジェクトに追加するからコピーされる。
じゃぁ、プロジェクト フォルダー外に置いたまま、プロジェクト フォルダーに持ってくれば良いじゃないか。
つまり、シンボリック リンクを作成する。
プロジェクト フォルダーにファイルへのシンボリック リンクを作成してみたのですが、"リンク"を Subversion に登録できなかった(実体になってしまった)。
で、フォルダーのリンクにして、リンクを作るバッチ ファイルを作ってみた。
リポジトリから取り出してきたとき、最初に1度だけ、バッチを実行する、と。
フォルダー構成は、こんな感じ。
Solution
 |−共通機能
 | |−共通機能を実現するためのソース コード ファイル
 |
 |−A様向けプロジェクト
 | |−共通機能へのシンボリックリンク
 | |−リンク作成バッチ
 | |−A様向け機能を実装するためのファイル
 |
 |−B様向けプロジェクト
 | |−共通機能へのシンボリックリンク
 | |−リンク作成バッチ
 | |−B様向け機能を実装するためのファイル

まぁ、P/Invoke の機能をひとつ所にまとめたい、かつ、お客様には実行ファイル単体で配布したい、ということで実験的に作ったソリューションなんだけど。
上記はソリューションの下にお客様毎のプロジェクトとしていますが、要はプロジェクトの下に共通部を収めたフォルダーへのリンクがあるということです。

こうすると、プロジェクト フォルダー下にあるファイルをプロジェクトに追加することになり、コピーは作られない。
機能的なことは共通機能に実装し、機能を実行する流れを個別プロジェクトに実装することで、他の顧客向けのオプションがあることを隠せるのではないかと思います。

# 「シンボリック リンク」と書きましたが、Windows では「接合ポイント」とか、「再解析ポイント」です。

解決済み
引用返信 編集キー/
■79555 / inTopicNo.8)  Re[5]: 顧客別オプションのうまいやりかた
□投稿者/ 作業着プログラマ (4回)-(2016/04/14(Thu) 11:04:17)
No79551 (Jitta さん) に返信

おお!これはすぐに実行できそうな内容です。
ソリューションごとコピーして顧客別に作り変えてましたが、
よく考えたらプロジェクトの追加で十分ですね。
共通部分のバグ修正も、ソリューションが1つなので一度で
直せますし。

なぜこんな簡単で効果的な事が思いつかなかったのか・・・・

大変勉強になりました。有難うございました。
解決済み
引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -