データ用にVisual Studioデザイナコンポーネントを使用する場合の賛否両論

Question

元の著者がMicrosoft Visual Studioのデータコンポーネント（データセット、データアダプタなど）を内部で使用している作業で、一連のプログラムを継承していますデザイン環境（ツールボックスまたはウィザードを使用して）これにより、データに特化したセミ・テーラード（semi-tailored）クラスが生成され、デザイナ生成クラスにSQLコードが格納されます。

これは私のやり方に慣れていません（データセットを明確に持たせたい、または独自の特殊なクラスを作成してデータを保持し、基になるデータレイヤーの複雑さを隠すことが望ましい）。

Visual Studioのデータコンポーネントを使用する際の賛否両論について、誰かに良い洞察やリンクがありますか？

（原作者も非常に徹底的にコメントしていませんでしたが、私の好みでは、あまりにも「巧妙」なコードを書いていますので、彼が知っているとは思っていません私よりも優れています）

データ設計者のコンポーネントを使用すると「ベストプラクティスに従う」コードが保守可能なのでしょうか？それは私のようには見えませんが、私は専門家からのインプットを探しています。など、プロトタイプに最適であることは本当にデザイナーのコンポーネントを使用する方法について

私が正しい（と私は同じように見える）場合には、私は：

[意図の明確化のためにいくつかのより多くのコンテキストを追加しましたEDIT]元の開発者と私のマネージャーといくつかの難しい会話をしなければならなくなるだろう。だから、私は "賛否両論の議論をするリンク"にもっと重点を置いていきたいと思っています。私は、このスタイルの開発/コードがもっともではないという主張を支持するために、プロダクション使用に適しています...ありがとう。

Answer 1

は使い捨て用途、POCのスパイクアプリケーション、すなわちプロトタイピングのためのものである

希望についての詳細を読むためにお勧めします。これはいくつかの理由によるものです。彼らは一緒になって非常に迅速ですが、維持するために完全な悪夢。私はあなたのアプリケーションのサイズを確信していますが、それは私の場合、私はそれが現在の形で所有権のコストは時間の経過と共に増加すると主張しているので、より多くのDDDスタイルの開発が必要になります。データレイヤーをビンに入れ、それを良いソリッドORMに置き換えます。 NHibernate（推奨）またはEntity Framework 4（より簡単に入手できます）。その「巧妙なコード」を削除し、Kiss, Yagni, dry mantraの使用を開始してください。彼らが光を見てもらうことは難しいかもしれないが、それはあまりの原価計算を開始したら、彼らはあなたがそれを好きになる;）

あなたがこの分野でいくつかのより多くの読み取りは、以下を見てみたい場合：

1. Skill Matterは公開セッションを実行するトレーニング施設であり、あなたが見ることができるポッドキャストのロード
2. Devと管理者の両方にとって良い本は、Ship ITです。良いプロジェクト実践を見ています。すべての事のための実用的な本棚
3. Martin Fowlers' blogに何がそうであるようにDDD
4. Ayende's blogはNHibernateの
5. stackoverflow.com、この場所は岩

Answer 2

VSデータコンポーネントの目的は、迅速なアプリケーション開発です。この観点から、あなたはその賛否両論を見ることができます：

プロ：速い開発は、多くのコーディングと知識を必要としません。将来変更されない小さなアプリケーションに適しています。

cons：すべてのファイルを1つにまとめるレイヤアプリケーション設計ロジック（このようなデザインのすべてのプロフェッショナルを追加）を破棄します。 結果として、データソースを動的に置き換えることはほとんど不可能です。より複雑な大規模なアプリケーションをサポートします。 DI、TDD - それを使って何か不思議なこと。

実際は非常に広い質問です。 は、私はN層アプリケーションの開発とテスト駆動開発の一般的なビジュアルコンポーネントには、このヘルプ

Answer 3

すべてのもののための素晴らしい場所です私は個人的にあなたが上の間違いだと思いますそれは本当にあなたがすでに持っているものと、製品の未来のための計画に依存しています。

私はあなたが話しているように使用し、うまく動作し、やや簡単に保守可能な生産コードを見てきました。 Telerikのような非常に大規模な企業のモジュールには、あなたが話しているのと同じ開発カテゴリに入るモジュールがあります。

あなたの雇用主にとって本当に重要な要素は、仕事を最も効率的に行うために何ができるかということです。しかし、一般的には、ドラッグアンドドロップツールはすぐに使えるので、長期的なエンタープライズレベルのアプリケーションにはあまり適していません。

チャールズ・ペッツォールドの記事は、より専門的な資格情報を提供するかもしれません。

http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

Answer 4

私もこれまでデザイナーDBコンポーネントはのPOCやプロトタイピングに適していますと言うことのように行かないだろう。これらのコンポーネントは、主にフレームワークの販売計画としてVisual Studioに組み込まれているため、マイクロソフトは「うわあ、.NETを使用してデータ駆動型アプリケーションを作成するのがいかに簡単か見ています」と言うことができます。彼らは数年前に削除されていたはずです、IMHO。

ただし、デザイナーコンポーネントをADO.NET（つまりDataTables、DataSets、DataReaders、DataAdaptersなど）と混同しないでください。あなたが継承したアプリケーションはデザイナーコンポーネントの周りに構築されているため、ADO.NETコンポーネントの周りにも基本的に組み込まれていました。あなたはデザイナーコンポーネントを取り除くことができます（そして、すべきです）が、必ずしもADO.NETも取り除くべきではありません。