17:57:17)通りすがりさんと凪瀬さんの意見を読んで状況が見えてきました。開発ソフトの高度化に比例して、我々技術者の技術力が落ちていると思ったら、こんなところにまで影響があるとは思いませんでした。この現象を考えていくと、以前皆さんと語り合った「品質と価格」の問題がまた頭をよぎりました。お客が商品の質を見極めないとなると、動くだけの品質が悪い商品を開発ツールでサックと大量生産すれば一番儲かるんですよね。この構図は昨今騒がれている食品偽装問題と同じものを感じました。我々技術者が世間に対して品質とか価値を提示できないのが問題なのかもしれません。現時点で1機能しか使わないかも知れません。将来的には複数機能から使うかも知れません。なさないと考えています。1機能からしか使われないのであっても分離する意義はあると思います。基本、別アセンブリ(分けるのであれば別アセンブリですよね。)で、ケースバイケースといった感じでしょうか?私にとっては、SQLが発生すると都度別メソッドになってしまうのが面倒だと感じました。メソッド名とか結構悩んじゃう・・・。(同じ名前がダブったりするともう考えるのが面倒になります。)しかし、規模が大きいものは別アセンブリにする意義がおおいにあると思っています。いった基本知識は大事にしていこうと思います。ありがとうございました。普段は回りに合わしておいて、こっそり技術力を高めて入念に準備をして転職してしまいましょう。転職ですよねwwwww。昨晩、9割真剣に考えてしまいました。やるだけやってみます。その間にこっそり技術力を高めて・・・。大手の仕様書の場合、確かに製作者に依存しない形の設計書も存在します。どの言語でも書けるが実装したほうが早いという形です。同期が合わなくなることもあります。大手ってドキュメント大好きですよね。やったら、そんなことになるんでしょうかね?小説のように字だけをズラズラ並べている人や、やたらハードコピーを貼って1ファイル数十Mみたいなこともありました。18:52:12)えーと、、、ぎゃふん分離ですか、今の自分にはそれを考えるだけの知識と経験が不足しているためとりあえず、このまま突っ走りますが余裕が出てきたら分離してみようかな。やるんだろう、ADO.NETではバインドとかあるしDataTable型を返すような仕組みが良いのかな?分からん・・・なるほど、渡世術とエルゴノミクス的な考え方はあらゆる場面に必要とそして、今自分は「いっぺん死んで来いと。おまけにドキュメントが複数あるおかげで、保守でも直す手間が、修正の2〜3倍ほどかかってしまい確かに大手はドキュメント多かったです。工数3あればドキュメント2でPG1でしたでも今いる所はドキュメント0です。これはこれで楽ですが担当者が居なくなったらどうするんだと仕様は常にプログラムを追って確認って、それは駄目でしょ。普段は回りに合わしておいて、こっそり技術力を高めて入念に準備をして転職してしまいましょう。このまま突っ走りますが余裕が出てきたら分離してみようかな。戻り値としてDataTable(データの中身)や、int(処理件数)、Bool(正常Or異常)を返す仕組みにしています。マスタ関係は、各テーブル項目をプロパティ化し、そのプロパティを摘んだり、セットしたりもします。私は独学なので「一般的」かどうかは分かりませんが、この手法はよく見かけます。今自分は「いっぺん死んで来いと。正確なものが出来上がります。仕様書の一言一句に悩むより、雰囲気を感じた方が全然いいです。ようは、雑な設計しかできないのに、なんで上から目線なんだ!というところに腹が立ちますね。いざ文字にすると、私はなんて小さい人間なんだ・・・。思っちゃいますね・・・(T_T)勝手ながら私はもうすっきりしましたので、解決済みとさせて頂きます。皆様、お騒がせ致しました。ありがとうございました。