oop - エンタープライズ開発にデータセットを使用しないように同僚を説得する方法 (.NET 2.0+)

Question

私が一緒に仕事をしている全員が、エンタープライズ開発へのデータ中心のアプローチに夢中になっており、カスタムコレクション/オブジェクトを使用するという考えを嫌っています。そうでなければ彼らを納得させる最善の方法は何ですか?

score 21 · Accepted Answer

例によってそれを行い、軽く踏んでください。より強いものは、チームの他のメンバーからあなたを遠ざけるだけです.

あなたが見逃した何かに彼らがいる可能性を考慮することを忘れないでください. チームの一員であることは、交代で学習と指導を行うことを意味します。

すべての答えを持っている人は一人もいません。

score 10 · Accepted Answer

レガシコード (.NET 1.x から 2.0 または 3.5 に移植されたアプリなど) を扱っている場合は、データセットから離れることはお勧めできません。すでに機能しているものを変更するのはなぜですか？

ただし、新しいアプリを作成している場合は、引用できるものがいくつかあります。

DataSet に固執するアプリを維持するのに苦痛を感じていることを訴える
新しいアプローチのパフォーマンス上の利点を挙げてください
良い中盤でそれらを餌にします。たとえば、.NET 3.5 に移行し、LINQ to SQL を促進します。たとえば、データ駆動型アーキテクチャに固執している間は、文字列インデックスデータセットへの大きな脱却であり、強制します... ほら! カスタムコレクション -- それらから隠されている方法で。

重要なのは、使用するアプローチが何であれ、一貫性を保ち、アプローチの長所と短所に完全に正直であることです.

他のすべてが失敗した場合 (たとえば、開発チームが古い慣行から完全に離れることを拒否し、新しいことを学ぶことに懐疑的である場合)、これは非常に明確な兆候であり、チームの能力を超えていることを示しており、会社を去る時が来ました。 !

score 9 · Accepted Answer

あなたが見逃した何かに彼らがいる可能性を考慮することを忘れないでください. チームの一員であることは、交代で学習と指導を行うことを意味します。

出向。「エンタープライズ開発」が通常の開発とはどういうわけか異なる (そして通常、その含意は「より重要」である) という全体的な考えは、私を本当にいらいらさせます。

テクノロジーを使用するメリットが本当にある場合は、切り替えた場合に生じるすべてのメリットとデメリットを考慮したリストを作成する必要があります。
このリストを、それぞれの説明と例とともに同僚に提示します。

このリストを作成するときは、現実的でなければなりません。「時間を大幅に節約できた!!! 勝った!!」とだけ言うことはできません。場合によってはそれ以上の時間がかかる、新技術に慣れるまでに X か月かかる、などの事実に対処せずに、時間を節約できる具体的な例と、正確な方法を示す必要があります。

同様に、短所が問題ではないかのように無視することもできません。
これらのことをしなかったり、自分の好きなことを押し付けているように見えたりすると、誰もあなたのことを真剣に受け止めてくれなくなり、熱意とエネルギーに満ちているのに何も知らない男だという評判を得るだけです。何でも。

ところで。この特定の詐欺に注意してください。他のすべてのものに対して多くの強力なケースがない限り、それはすべてに勝ります:

既存のコードの移植には 12 か月以上の作業が必要です。あなたは負けます。

score 7 · Accepted Answer

もちろん「場合による」。非常に軽いビジネスロジック、エンティティ/レコードのフラットな階層、またはいくつかのバージョン管理機能を備えている場合など、DataSets または DataTables がより適している場合があります。

カスタムオブジェクトコレクションは、フラットな 2D テーブルでは効率的に表現できないオブジェクトの深い階層/グラフを実装する場合に役立ちます。あなたが実証できるのは、オブジェクトの大きなグラフであり、特定のイベントを取得して、他のブランチで不適切なオブジェクトを呼び出すことなく、正しいブランチに伝播します。そうすれば、子レコードを取得するためだけに、すべての DataTable をループまたは Select する必要はありません。

たとえば、私が 2 年半前に関わったプロジェクトでは、単一の WinForms DataGrid (具体的には Infragistics の UltraGrid) に質問と回答のコントロールを表示することになっている UI モジュールがありました。さらにトリッキーな要件

質問の回答コントロールは、テキストボックス、チェックボックスオプション、ラジオボタンオプション、ドロップダウンリスト、さらには Web サービスからより多くのデータを取得できるカスタムダイアログボックスをポップアップするものなど、何でもかまいません。
ユーザーが回答した内容に応じて、親の質問のすぐ下にサブ質問が表示される可能性があります。後で別の回答が与えられた場合、その回答に関連するサブ質問の別のセット (存在する場合) を公開する必要があります。

元の実装は、完全に DataSet、DataTable、および配列で記述されていました。複数のテーブルの何百もの行をループする量は、まったく気が遠くなるようなものでした。C++ 出身のプログラマーがすべてを参照しようとするのを助けませんでした(こんにちは、ヒープ内に存在するオブジェクトはポインターなどの参照変数を使用します!)。元のプログラマーでさえ、コードがなぜそのように動作するのかを説明できませんでした。このシーンから 6 か月以上経った今でも、バグだらけでした。引き継いだ二代目の開発者が辞めたのも無理はない。

この混沌とした混乱を修正するために 2 か月を費やした後、この問題を解決するためにモジュール全体をオブジェクト指向グラフに再設計することにしました。はい、抽象クラス（質問の種類に応じてグリッドセルに異なる回答コントロールをレンダリングするため）、デリゲート、およびイベントを完備しています。最終結果は、質問の深い階層にバインドされた 2D dataGrid であり、親子の配置に従って自然に並べ替えられました。親の質問の回答が変更されると、子の質問にイベントが発生し、親の回答に従ってグリッド内の行を自動的に表示/非表示にします。そのパスの下にある質問オブジェクトのみが影響を受けました。このソリューションの UI 応答性は、古い方法と比較して桁違いでした。

score 5 · Accepted Answer

皮肉なことに、これとは正反対の質問を投稿したかったのです。私が一緒に仕事をしたプログラマーのほとんどは、カスタムデータオブジェクト/コレクションアプローチを採用しています。あるモニターで SQL Server テーブル定義を開いて、別のモニターで Visual Studio の一致する行ラッパークラスをゆっくりと入力している (各列のプライベートプロパティと getter-setter を完備している) のを見ていると、心が痛みます。また、60 列のテーブルを作成する傾向がある場合は特に苦痛です。これらのクラスを自動的に構築できる ORM システムがあることは知っていますが、手動のアプローチがより頻繁に使用されるのを見てきました。

エンジニアリングの選択には、利用可能なオプションの長所と短所の間のトレードオフが常に含まれます。DataSet 中心のアプローチには、カスタムデータオブジェクトと同様に、利点があります (実際の db データの db テーブルのようなメモリ内表現、自分が何をしているかを知っている人によって書かれたクラス、開発者の大規模なプールに精通しているなど)。 (コンパイル型チェック、ユーザーは SQL などを学ぶ必要はありません)。社内の他の全員が DataSet の道を進んでいる場合、少なくとも技術的には、DataSet がその作業に最適な選択である可能性があります。

score 3 · Accepted Answer

データセット/テーブルはそれほど悪くありませんか?

私ができる最善のアドバイスは、自分のコードでできる限り使用することです。うまくいけば、他の開発者は、ピアレビューとバグ修正を通じて、コードがより読みやすくなる方法を確認できます。（これらの発生が発生したときに必ずポイントを押してください）。

最終的にコードが機能する場合、残りはセマンティクスであり、私の見解です。

score 2 · Accepted Answer

相互運用性が今後懸念される場合、DataSetは間違いなく正しい方向ではありません。サービスを介してDataSets / DataTablesを公開することはできますが、すべきか議論の余地があるかは関係ありません。.NET->。NETについて話している場合は、おそらく大丈夫です。そうでない場合は、フェンスの向こう側から非常に不幸なクライアント開発者がサービスを消費することになります。

score 2 · Accepted Answer

それを宗教や信仰の議論にしないでください。それらは勝つのが難しいです（そしてとにかくあなたが望むものではありません）

質問で行ったようにフレーム化しないでください。問題は、この方法またはその方法が彼らが働くべき一般的な方法であることに誰もが同意することではありません。いつでも正しい選択をするために、それぞれがどのように考える必要があるかについて話し合う必要があります。dataSetを使用する場合と使用しない場合の例を示します。

開発者にdataTablesを使用してデータベースから取得したデータを保存し、そのdataTableを使用してビジネスロジックコードを作成してもらいました...そして、ページの読み込みにかかる時間を7秒の100％CPU（Web上）から短縮する方法を示しました。サーバー）メモリオブジェクトをdataTableからHashテーブルに変更することにより、CPUラインがまったく移動しないようにします。

ですから、あなたのことを別の方法で実装したほうがよいという例や事例を取り上げて、その戦いに勝ちましょう。高レベルの戦争と戦わないでください...

score 2 · Accepted Answer

O/R マッピングとマッパーツールのアイデアを売り込んでみてはいかがでしょうか。行をオブジェクトとして扱う利点は非常に強力です。

score 2 · Accepted Answer

パフォーマンスに集中するべきだと思います。DataSet とカスタムエンティティを使用した場合のパフォーマンスの違いを示すアプリケーションを作成できれば。また、ドメイン駆動設計の原則と、それがエンティティフレームワークにどのように適合するかを示すようにしてください。

score 1 · Accepted Answer

そうでなければ、彼らを納得させることはできません。より小さな課題を選ぶか、別の組織に移動してください。あなたのマネージャーが尊敬しているなら、一種のテクノロジートライアルとしてドメイン主導型のスタイルでプロジェクトを行うことができるかどうかがわかります.

score 1 · Accepted Answer

プロファイルできる場合は、実行してプロファイルするだけです。データセットは単純なものよりも重いCollection<T>

DataReaders は、アダプターを使用するよりも高速です...

オブジェクトの動作を変更することは、データセットを操作するよりもはるかに簡単です

とにかく: やればいい、許可ではなく許しを請う。

score 1 · Accepted Answer

ほとんどのプログラマーは、コンフォートゾーンから外れるのを好みません (「ほとんどのプログラマー」セットと「スタックオーバーフロー」セットの交点は、おそらく空のセットであることに注意してください)。「以前に機能していた場合 (または機能したばかりである場合) は、それを続けてください」。私が現在取り組んでいるプロジェクトでは、年配のプログラマーに CSV ファイル (以前のバージョンのソフトウェアは CSV を使用していました) の代わりに XML/スキーマ/データセットを使用させるために多くの議論が必要でした。完璧ではありません。スキーマは、データを検証するのに十分堅牢ではありません。しかし、それは正しい方向への一歩です。私が開発するコードは、データセットオブジェクトを渡すのではなく、データセットで OO 抽象化を使用します。一般に、例を挙げて、一度に 1 ステップずつ教えるのが最善です。

score 0 · Accepted Answer

小さく始めましょう。ポイントを説明するために使用できるユーティリティアプリはありますか?

たとえば、私が働いていた場所では、メインアプリケーションのビルドプロセスが複雑で、構成ファイルの変更やサービスのインストールなどが含まれていました。

そこで、ビルドプロセスを自動化するアプリを作成しました。初歩的な WinForms UI がありました。しかし、WPF に移行していたので、Model-View-Presenter のおかげで、WinForms UI も維持しながら、WPF UI に変更しました。Model-View-Presenter になじみのない方にも参考にできる分かりやすい例でした。

同様に、大規模な開発投資を行うことなく、DataSet 以外のアプリがどのように見えるかを示すことができる小さなものを見つけてください。

score 0 · Accepted Answer

ここにはすでにいくつかの非常に良いアドバイスがありますが、バックアップする必要があるのがstackoverflowに関するいくつかの支持的なコメントだけである場合でも、同僚を説得する仕事があります. そして、彼らが思うほど懐疑的であれば、より多くの弾薬が必要になります。まず、Martin Fowler の「Patterns of Enterprise Architecture」のコピーを入手してください。これには、さまざまなデータアクセス手法の詳細な分析が含まれています。それを読んで。そして、全員に強制的に読んでもらいます。

ジョブ完了。

oop - エンタープライズ開発にデータセットを使用しないように同僚を説得する方法 (.NET 2.0+)

16 に答える 16

Related

Reference