DataTableについて複数個所から変更されるデータに連動して同じ行のデータを変更する場合の実装方法について

Question

お世話になります。
経験が浅く、プログラミングのベストプラクティスのようなものがわからないため教えてください。

前提

私のスキルレベル

• VB.NETで簡単な画面アプリを作れる程度

環境

• Windows 10 （開発環境・動作環境ともに）
• VB.NET (VisualStudio2017pro)
• SPREAD 11J
• Oracle Managed Driver

重視する点

• 効率性も見ないわけではないですが、ソースコードの可読性や保守性を重視します。
• 改修頻度は年に数回程度です

内容

DataTableについて複数個所から変更されるデータに連動して同じ行のデータを変更する場合の実装方法について

詳細

VB.NETにて、ユーザ手入力、RS232cなどで入力されたデータをOracleDBに保管するクライアントアプリを開発しています。

処理の流れは大まかに以下の通りです。

1. OracleDBに保存されたデータをDataTableにFillする
2. DataTableに保管されたデータをSPREADのDatasoruceに紐づけて画面にスプレッドシートを表示
3. ユーザ手入力、バーコードリーダ入力、デジタル入力、RS232c通信入力があれば画面 プレッドシートに反映
   この時、A列が変更されたら自動的にB列を変更するような処理があり、A列は様々な処理から変更されます
   上記のB列自動変更処理については、SPREADのdatamodel.ChangedイベントでA列の変更を検知してB列を変更しています
4. 変更されたデータをOracleDBに保存

そのような中でSPREADのバージョンアップを行ったところ、それまでのバージョンが出ていなかったStackOverflowExceptionエラーが表示されてしまいました。

エラーが表示されたこともあり、B列自動変更処理の見直しを行っています。

お聞きしたい点

現在は下記①で実装していたのですが、②や③のような実装方法も考えられ、皆様はこのような場合はどのように処理されているか教えてください。

1. 詳細で書かれているように、A列の変更イベントをトリガーにしてB列を変更する

• メリット：　改修の際に１か所の変更でよい、改修の際に処理忘れなどがない
• デメリット：　イベントの存在を知らないと勝手にデータが変わったかのようにふるまう、処理の流れが乱れるためデバッグがしにくい、ミドルウェアに依存してしまう

1. A列を変更するすべての関数にてB列の変更処理を行う。

• メリット：　データの処理が見やすい、デバッグしやすい、ミドルウェアに依存しない
• デメリット：　改修の際に変更忘れなどが発生する

Answer 1

1.詳細で書かれているように、A列の変更イベントをトリガーにしてB列を変更する

方法としてはこれが普通かと。
メリットは書かれているとおり。

デメリット：　イベントの存在を知らないと勝手にデータが変わったかのようにふるまう、処理の流れが乱れるためデバッグがしにくい、ミドルウェアに依存してしまう

むしろ処理の流れは「様々方法の入力」に反応してデータが更新されるわけで、わかりやすくなっていると思うんですが。（入力方法ごとに処理を追わなければいけないとしたらその方が大変）

あと「ミドルウェアに依存」ってのは単にコンポーネントのイベントを使うから発生する話だと思うので、データセットの側で変更検知して更新してやればいいだけな気がします。

Comments

[garakutayama]

ご返信ありがとうございます。

①が普通とのことで少し安心しました。

不安になった理由が、社内の過去の類似ソースコードは②で実行されていること、
エラーになったことを同僚に話した際に②を提案されたことがあったからでした。
②を勧められた際の理由として、処理がわかりにくいとあったのでデメリットに書きました。つまりソースコードを見た場合に処理フローが見にくくなってしまう。Sub A列変更　⇒(暗黙的に飛ぶ)⇒　DataTable.Changed　と処理されることが、```goto```構文のように処理のフローがわかりにくくなることにつながるのではとのことでした。

仕様書とセットで確認する癖が社内でないことや、また私のような処理をしているソフトが社内で少ないので、コメントを書くなど相談してみたいと思います。

＞＞あと「ミドルウェアに依存」ってのは単にコンポーネントのイベントを使うから発生する話だと思うので、データセットの側で変更検知して更新してやればいいだけな気がします。
確かにそうですね。
DataTableのリファレンスを確認し、また月曜にでもトライしようと思います。

[gentaro]

オブザーバーパターンを知ってれば全然普通だと思うんですけどね。むしろ色んなところで同じ処理の呼び出しをやる方がDRY原則を破ってるわけで、アンチパターンだと思うんですけど…。

[garakutayama]

恥ずかしながら、DRY原則というものを知りませんでしたが、今回の件で②の実装をするとまさしくその原則に違反すると思います。
大変勉強になりました。

私事なのですが、社内には20～30の古いアプリケーションがありますが、”動けばいい”というプログラムが多く、毎回苦労しています。
今回の件も踏まえ、基礎的な勉強からしていき社内でのスキルアップも考えていきたいと思います。

初心者の内容にもかかわらずご丁寧にありがとうございました。

[gentaro]

失礼ながら、そういった環境では業務知識はともかくとして、プログラミングに関しては社内の方のアドバイスは基本的にあまりアテにしない（で問題解決ができるようになる）方が良いと思います。
ただ、メンテするメンバーのレベルに合わせて理解しやすい実装が必要になる事もあると思いますので、そういう意味ではあまりあるべき論に囚われすぎず、妥協点を探りながらやっていく感じが良いとは思いますが…。
まぁそのあたりは立場によって出来ることも変わってくると思うので、柔軟に対応しましょう。

[garakutayama]

ご丁寧にアドバイスまでで頂きましてありがとうございました。
回答いただいた内容をもとに提案し、短期的には妥協点の模索、長期的には風土改善に取り組みたいと思います。

また二つ前のご回答でアドバイスいただいたDataTableの変更イベントについても問題なく取れましたことを合わせてご報告いただきます。

gentaro様のおかげで本案件のほうは解決したものとさせていただきます。
ありがとうございました。

[gentaro]

お役に立てたのであれば何よりです。
難しい問題はあろうかと思いますが、前向きに進んでおられるようなので、これからもその調子で頑張って下さい。