インターフェイスをバージョン管理できないため、抽象基本クラスに切り替えられます。

非仮想メソッドは仮想である別のメソッドを呼び出すと思います。 仮想メソッドはパフォーマンスを低下させるため、不必要に仮想化することは望ましくありません。

@JamesNKなるほど。 しかし、.NET Coreは新しいAPIであり、ADO.NET APIはほぼ10年にわたって非常に安定しているため、これは依然として有効な懸念事項だと思いますか？ また、データベースアクセスについて話すと、仮想メソッドのコストはデータベースアクセスのコストよりも小さいと思います。

@ NickCraver 、 @ roji 、 @ FransBouma皆さんはADO.NETAPIに興味を持っているようですが、これについて何か言いたいことがありますか？

@YoungGah 、これは追求する価値のあるものですか？

非仮想メソッドは仮想である別のメソッドを呼び出すと思います。 仮想メソッドはパフォーマンスを低下させるため、不必要に仮想化することは望ましくありません。

リモートデータベースでクエリを実行して結果を処理するプロセスでは、virtcallで失われるナノ秒はごくわずかです。 その上、ADO.NETは最初からこのシステムを使用しており（.NETの他の多くのAPIもそうです）、仮想メソッド呼び出しのためにDBコードが非常に遅いと誰も文句を言いませんでした;）

私はあなたのリストに非同期メソッドを見ることができるので、ほんの数年前にMSがIDbCommandに非同期を追加できなかったと思います。 明日が何をもたらすかを誰が知っているのか、それは新しいメソッドやプロパティを必要とします。

インターフェイスはバージョン管理されません。

パフォーマンスは、何かを仮想化しない理由の1つにすぎません。 多分、含意のための表面積を減らす？ MSの誰かに、なぜそうしないことに決めたのかを言わせます。私はADO.NETについてあまり知らないので、推測しているだけです。

@JamesNKあなたの懸念は正しいと思いますが、考慮すべき2つの重要なポイントがあります。

1. ADO.NETは、.NET 2.0以降かなり安定しています。10年後、非同期APIは後で追加されましたが、APIの動作は変更されず、非同期の対応するものが追加されました。大きな変更はありません。データベースドライバのパラダイムはいつでもすぐに
2. CoreFxは、古いアプリ用に以前のCLRをそのまま保持できるため、異なるバージョン管理のアイデアを持っているはずです。 したがって、インターフェイスのバージョン管理の問題がここでそのような影響を与えることはないはずです。

「localhost」上のSQLサーバーでさえ、接続して空のクエリを返すためだけに少なくとも数ミリ秒を費やすことも考慮してください。 実際には、リレーショナルデータベースへのほとんどの_fast_クエリには約20ミリ秒かかります。

NSubstituteやMoqなどの標準ツールを使用してAPIをモックできることは、仮想メソッドルックアップでマイクロ秒を節約するよりも、今日の開発者にとってはるかに価値があります。

私はここであまり強い意見を持っていないと思いますが、ここにいくつかの意見があります：

• データベースアクセス用のAPIでは、仮想と非仮想の削除はごくわずかであるという上記の点に同意します。
• 基本クラスはADO.NETが実装を提供することを可能にします、私はそれがほとんどの非仮想非抽象メソッドについてであると推測しています-CommandBehaviorを受け入れないExecuteReaderのオーバーロードはCommandBehavior.Defaultをオーバーロードに渡しますそうです。 インターフェイスに切り替える場合、すべてのプロバイダーはまったく同じ定型文でExecuteReader（）を実装する必要があります...
• これがすべての主要なモックフレームワークで有効かどうかはわかりませんが、少なくともMoqでは、インターフェイスであるのと同じくらい簡単に基本クラスをモックすることができませんか？

したがって、全体として、基本クラスまたはインターフェースのいずれかを削除するという考えは良いように思われます（より単純です）。 インターフェイスに利点は見当たらず（モックのしやすさについて間違っていない限り）、基本クラスは共通の機能（つまり、非仮想の非抽象メソッド）を提供できるため、インターフェイスをダンプするMicrosoftのアプローチを推測します。私には良さそうです...

私は彼のすべての点で@rojiに同意します。

@rojiは、基本クラスを削除することを提案しているのではなく、デフォルトのAPIとしてインターフェイスを追加することを提案しています。 基本クラスは引き続きデフォルトの動作を実装できます。

テストに関しては、APIが適切なメソッドを呼び出しているかどうかのテストで大きな問題が発生しました。 たとえば、ExecuteDataReaderが正しいパラメータを受け取ったかどうかを確認するには、異なるパラメータで内部的に呼び出される別の保護されたメソッドを確認する必要があります。 これは理想からは程遠いです。

現在、私が間違えない限り、ADO.NET APIをモックできる唯一のフレームワークは、呼び出しをインターセプトすることで絶対に何でもモックできるMSFakesフレームワークです。 Moqや他の人はそれを行うことができません。

他の人にも同じような問題があったかどうか興味があります。

@rojiは、基本クラスを削除することを提案しているのではなく、デフォルトのAPIとしてインターフェイスを追加することを提案しています。 基本クラスは引き続きデフォルトの動作を実装できます。

すみません、誤解しました。 その場合、あなたの提案は多かれ少なかれ.NETの状態を維持していませんか（それは何か問題があるわけではありません）？

テストに関しては、APIが適切なメソッドを呼び出しているかどうかのテストで大きな問題が発生しました。 たとえば、ExecuteDataReaderが正しいパラメータを受け取ったかどうかを確認するには、異なるパラメータで内部的に呼び出される別の保護されたメソッドを確認する必要があります。 これは理想からは程遠いです。

私があなたのシナリオを理解している場合（わからない）、MoqのCallBaseはこの種のシナリオに役立ちます-デフォルトの実装は基本クラスから継承されます

@roji

あなたの提案は多かれ少なかれ.NETの状態を維持していませんか（それは何か問題があるわけではありません）？

ではない正確に。 インターフェイスAPIは.NET1.0で追加され、2.0で非推奨になりました。 2.0以降、インターフェイスは互換性のためにありますが、Data.CommonにはProviderFactoryまたは他のクラスのインターフェイスはありません。 非同期APIまたは2.0以降のメソッドにも何もありません。

Moqは、モック可能なもののみをモックできます。 オーバーライドできる仮想または抽象のメソッド、または呼び出すことができる保護されたメソッドが必要です。 現在のAPIは、場合によってはメソッドを提供しますが、ほとんどの場合は提供しません。 リフレクションを使用しない限り、内部的、プライベート、そして手の届かないものがたくさんあります。 参照をシムに置き換えるため、MS Fakesのみがそれを実行できますが、これはVS Enterpriseでのみ使用可能であり、オープンソースプロジェクトには役に立ちません。

私には非常に特殊なケースがあるようですが、確かにこのAPIをモックしようとした人は誰でもこの問題に直面しました。 グーグルだけで、ほとんどすべてのソリューションは「レガシーインターフェースAPIをモックするか、モックできるラッパーを構築する」ことになります。

@nvivo OK、追加の詳細に感謝します-私はADO.NETをあざけることについてあまり進んでいないことを認めます。

私が理解していないのは、APIの内部メソッド、プライベートメソッド、またはその他の方法で手の届かないメソッドをモックしたい理由です。 自分のアプリケーションコード（テストしようとしているもの）で直接利用できるパブリックメソッドをモックするべきではありませんか？ 非仮想メソッド（たとえば、0パラメーターのExecuteReader（）オーバーロード）に問題がありますが、ADO.NETでは、これらは常に（？）仮想オーバーロード（たとえば、ExecuteReader（CommandBehavior））を呼び出します。ここで本当の問題？

問題のシナリオを理解しようとしているだけで、簡単な例を挙げていただけますか？

@nvivo現在、このスレッドで数人の人からすでに指摘されているバージョン管理の問題のため、インターフェイスを導入する予定はありません。 遅れをとっているインターフェースの良い例は、非同期およびストリーミングメソッドが.NET Framework4.5で追加されたときです。 これらの新機能を追加する際に、インターフェースの拡張を慎重に検討しました。 当時私たちが持っていたオプションは、InterfaceFooV2を提供するか、asynとストリーミング用に別々のインターフェースを提供することでした。 将来さらにAPIを追加したいと予測できるため、InterfaceFooV2を追加したくありませんでした。 新しい機能ごとに個別のインターフェースを追加し続けると、既存のインターフェースに関連付けられていないため、混乱を招きます。

@roji 「オーバーロードのいずれか」ではなく、ExecuteReaderの特定のオーバーロードが呼び出されたことを確認したい場合がありました。 これは、ユーザーコードではなく、ライブラリにのみ存在するようなものです。

@YoungGah情報をありがとう。 それではこれを閉じます。

この変更の責任者は、その影響について何か考えを持っていますか？ コアのADO.NETインターフェイスは10年以上前から存在しており、データアクセスはほとんどのビジネスアプリの中心です。多くの既存のコードベースを意図的に壊さないことが最優先事項ではないことを想像するのに苦労していますか？ これらは、.NETで最も重要な高レベルのインターフェイスの一部であり、これらを削除すると、すべてのADO .NETデータアクセスライブラリが破損し、その結果、すべてのプロジェクトがそれを使用します。 それらを削除すると、人為的な断片化が発生し、CoreCLRの採用を妨げるフラストレーションと混乱が発生します。

IDbCommand以外の新しいAPIの拡張メソッドを追加するだけで、インターフェースをバージョン管理してソース互換にすることができます。例：

public interface IDbCommand
{
    //...
}

public class DbCommand : IDbCommand
{
    void NewApi();
}

public static class DbCommandExtensions
{
    public static void NewApi(this IDbCommand cmd)
    {
        ((DbCommand)cmd).NewApi();
    }
}

コアのIDbCommandインターフェイスは、DNXのリリース後に変更する必要はなく、上記の戦略で機能を追加し続けることができます。 後で（メジャーブレイクバージョンで）、これらの拡張機能をロールアップしてコアインターフェイスにマージすることもできます。 いずれにせよ、既存のコードベースの移行とその結果としてのCoreCLRの採用に不可欠なコアの安定したADO.NETインターフェイスを取得します。

@davkeanから、コアADO.NETインターフェイスの削除がどのような影響を与えるかについて具体的な例を提供するように依頼されました。 この変更が既存の.NETエコシステムに与える計り知れない影響を評価せずに検討されたとは想像できませんが、再度行われたため、検討されなかった可能性があります-これをここで想定します-そうではありませんでした。

.NETのデフォルトORMであるというEFの役割と、市場シェアの大部分を獲得するというその卓越した成功にもかかわらず、さまざまな理由で代わりに代替ORMを使用することを好む.NET開発者は依然として多数います。 たとえば、CoreCLRに関連する重要な機能は、Mono / Linux / OSXで実行されるファーストクラスのサポートと、複数の代替RDBMSをサポートすることです。 CoreCLRはLinux / OSX開発者市場に大きく売り込んでいるため、代替RDBMのサポートが多ければ多いほどよいでしょう。 マイクロORMを採用する開発者の人口のもう1つの重要な特徴は、MSエコシステムのデフォルトの外で評価して、自分に最も適したORMを選択したことです。 私が見たすべてのことから、アクティブな.NET OSS（つまりアンチダークマター）開発者とマイクロORMを採用する開発者の間には高い相関関係があります。同様に、これはCoreCLRの早期採用者と高い相関関係があると予想しています。 OSX / Linuxで開発します。 これらは、このような根本的な破壊的な設計の選択を行うときに、周囲の.NETエコシステムを意思決定に含めることが有益である理由のいくつかです。

代替ORMダウンロード

NuGetのダウンロードをざっと見ると、EF以外の市場シェアがどのようになっているのかがわかります。

NHibernate -1M +
ダッパー-1M +
OrmLite -
Simple.Data -
PetaPoco -
NPoco -30k +

Dapper、Massive、PetaPoco、NPocoなどの多くのMicro ORMは、単一のドロップイン.csに収まるように設計されているため、実際の数値はこれをはるかに上回っているため、NuGetは実際の使用状況を報告していません。 LLBLGen Proのような大規模なユーザーベースを持つクローズドソースORMもありますが、その使用法はNuGetによって報告されていません。同様に、私が忘れた/知らない他の多くのORMを見逃したと確信しています。

代替ORMへの影響

GitHubのおかげで、コアが含まれているさまざまなソースファイルの数をすばやく検索できます
IDbConnection 、 IDbCommand 、およびIDataReaderこの変更の影響を受けるADO .NETインターフェイス：

注：これらの結果はソースファイルのみを示しており、壊れた参照の実際の数ははるかに多くなっています。

顧客のソースコードへの影響

この変更の実際の影響は、これらのORMを使用するすべてのプロジェクトの依存関係にも及びます。
残念ながら、その影響は内部実装に限定されるものではなく、顧客をも破壊します。
多くのMicroORMのソースコードはADO.NETインターフェイスを介した単なる拡張メソッドであるため、クライアントは
コードは次のようになります：

IDbConnection db = ...

//Dapper
db.Query<Dog>("select Age = <strong i="49">@Age</strong>, Id = @Id", new { Age = (int?)null, Id = guid });

//OrmLite
db.Select<Author>(q => q.Name.StartsWith("A"));

拡張メソッドを使用することによる拡張機能の1つは、これらのORMが「オープンエンド」であり、顧客が独自のプロジェクトに拡張メソッドを追加することで、独自のファーストクラスAPIを使用してORMを拡張できることです。これらも壊れています。

明らかに、 IDbConnectionを渡すソースコードもCoreCLRでの作業が禁止されています。

たとえば、コアADO.NETインターフェイスは、マルチRDBMSデータアクセスを有効にするための最小限の依存関係であるため、ServiceStackなどの高レベルフレームワーク全体で頻繁に使用されます。 また、変更される可能性が低いすべてのクラスから、コアADO.NETインターフェイスになると想定されていました。

概要

私は個人的に、これらのインターフェースなしで.NETに未来があることに驚いています。
インターフェースは、複数の実装を可能にするために設計目的固有であり、ADO.NETは1つです。
.NETで最も重要な「オープンプロバイダーモデル」のこれらのインターフェイスが削除された原因が何であるかはわかりませんが、これらのインターフェイスに依存する既存の大規模な.NETコードベースと代替EF.NETエコシステムの両方にはるかに高い優先度を与える必要があります。 これは重大な混乱を引き起こしており、既存の.NET 4.xプラットフォームとCoreCLRプラットフォームの両方をサポートするために必要な主要な障壁であり、これによって影響を受けるすべての既存のコードベースに適用する必要がある重要な追加の複雑さを余儀なくされます。

現在の認識では、ADO.NET / CoreCLRは、EFとSQL Serverのファーストクラスのサポートを提供するように再設計されており、残りのエコシステムは無視されています。このような不透明な決定は、このステレオタイプを強化するためだけに行われます。 。

.NETチームの以前のメンバー（現在はRoslynで作業しています）として、SQLチームとEntity Frameworkチームとともに、新しいデータ共通の元の設計に深く関わっていました。 現時点では関与していませんが、Twitter以上で見ているステートメントの一部を修正するのに役立つ背景を追加できます。

System.Data.Common for .NET Coreの現在の設計は、オープンソースの約2年前の2012年12月に開始されました。

目標：

• .NET Coreの最新の表面領域を設計し、概念の重複（ IDbConnectionとDbConnection ）、混乱、間違い、階層化の問題（DataCommonからSqlClientを分割、コア抽象化からDataSetを分割）を削減します。 .NET1.0の元のデザイン。 既存の消費者と.NETFrameworkの_新しい_開発者の両方が簡単に手に入れることができるもの。
• プロバイダーとコンシューマーが.NETCoreに対して単一のバイナリ/ソースを構築し、同じバイナリを.NETFrameworkで実行できるようにします。 注意してください、逆は目標ではありませんでした。 .NET Frameworkのバイナリ/ソースを取得して、.NETCoreで変更を加えることなく実行できること。

周りに広がっているいくつかのことの修正：

• 現状のインターフェースはバージョン管理できません。 インターフェイスにメンバーを追加することはできません。 @ mythzが拡張メソッドを介して提供する上記の提案では、プロバイダーはとにかく抽象基本クラスから派生する必要があります。
• System.Data.Commonは、プロバイダーモデルから移動していません。 インターフェイスは、.NET2.0で導入された抽象基本クラスによって置き換え/複製されたレガシー.NET1.0の概念であったため、削除されました。 この決定を行った時点で、見つかったすべてのプロバイダーは基本クラスから派生していました。
• インターフェイスと同様に、基本クラスはモック可能です。
• .NET 1.0インターフェイスを使用している場合は、いくつかの変更が必要になることは理解していましたが、基本クラスに移動するのは非常に簡単なポートです。 たとえば、AutoMapperの次の数行の変更を参照してください：（https://github.com/AutoMapper/AutoMapper.Data/blob/master/AutoMapper.Data/DataReaderMapper.cs#L14）。

私が理解するのに苦労していること：

インターフェイスにメンバーを追加できません

まだCoreCLRインターフェイスにメンバーを追加するのは問題ありませんが、メンバーを完全に削除しても問題ありませんか？

拡張メソッドを介して@mythzによって提供された上記の提案では、プロバイダーはとにかく抽象基本クラスから派生する必要があります。

重要な部分は、インターフェースが存在し、それらを参照するソースコードがコンパイルできるようにすることです。

インターフェイスをバージョン管理したくない場合は、EOLを細かく設定し、インターフェイスを削除する前の状態に復元して、インターフェイスを使用する他のすべてのライブラリにかかる負担を軽減します。 つまり、これらのコアインターフェイスは、警告や移行パスが提供されずに廃止されることはありませんでした。 それでも、公開された、よく知られている、安定したAPIをライブラリの不可欠な部分として採用したことで罰せられていますか？

これは、基本クラスに移動するための非常に単純なポートです。

これは、ADO.NETインターフェイスを参照するすべてのソースファイルに追加する必要があり、顧客はカスタムビルドシンボルを使用してコードを散らかす必要があります。

ここでは下位互換性について同じ注意が払われていないようですが、将来のリリースで既存の顧客を故意に壊すことは選択肢ではありません（ADO .NETのはるかに大きな市場シェアで考慮されていることに驚いています）。 既存の4.xの顧客を壊すことはできませんが、CoreCLRのサポートを求められています-では、既存の下位互換性を維持し、CoreCLRもサポートしたい既存の4.xライブラリはどこに残るのでしょうか？ ドキュメント/例も複製する必要がありますか？

まだCoreCLRインターフェイスにメンバーを追加するのは問題ありませんが、メンバーを完全に削除しても問題ありませんか？

.NETCoreの表面積は.NETFrameworkとバイナリ互換である必要があります。これにより、ファーストパーティとサードパーティが.NET Coreに対して構築し、.NETFrameworkを変更せずに移植性を実行できるようになります。 .NET Frameworkで実行すると、それらのメンバーのコンシューマーが失敗するため、インターフェイスにメンバーを追加すると、これに違反します。

これらのインターフェイスの削除や追加については議論していません。デザインが最終的にどこにあるのかについて、背景を追加したかっただけです。 @YoungGahや@ saurabh500を含む現在の所有者にもらいます。

スレッドを要約すると、Microsoftがこれらのインターフェイスを移植する必要があると考える理由は、.NET Frameworkの実装を維持しながら、エコシステムが.NETCoreに簡単に移植できるようにするためです。

.NET Frameworkの実装を維持しながら、エコシステムを.NET Coreに簡単に移植できるようにすることですか？

はい。

スレッドを要約すると、Microsoftがこれらのインターフェイスを移植する必要があると考える理由は、.NET Frameworkの実装を維持しながら、エコシステムが.NETCoreに簡単に移植できるようにするためです。

はい。 コードベース（LLBLGen Pro）をcorefxに移植すると、外部APIが壊れます。次に、2つのAPIを公開するか、すべてのユーザーの既存のコードベースを壊す必要があります。

あなたが痛みを感じないので、あなたの人々が私たちのものを壊すのは良いかもしれません、私たちはそうします。 私には問題がありません。私は、破壊されたコードベースを使用して同じことを行う2つのAPIを維持するか、それで問題ないと思ったためにユーザーのコードを壊す必要があります。

また、インターフェイスがバージョン管理されない理由もわかりません。クラスにもインターフェイスがあるように、これは単なるインターフェイスです。 CoreFXは、非同期メソッドをインターフェイスに完全にうまく追加できます。

.NETCoreの表面積は.NETFrameworkとバイナリ互換である必要があります。これにより、ファーストパーティとサードパーティが.NET Coreに対して構築し、.NETFrameworkを変更せずに移植性を実行できるようになります。 .NET Frameworkで実行すると、それらのメンバーのコンシューマーが失敗するため、インターフェイスにメンバーを追加すると、これに違反します。

簡単な解決策：現在のインターフェースを追加します。 そして、上記のルールが実際にはかなりばかげていることに気づいたら、ずっと前にインターフェイスに追加する必要があったメソッドをインターフェイスに追加して、先に進むことができます。

私はMSソフトウェアを十分に長く使用しているので、上記のようなルールは紙の上では優れていますが、実際には、重要なMSチームがそれを破る必要がある2番目に破られます。 あなたが言うようにあなたがCoreFXmarketing / pr hooplaにいるように「オープン」で「違う」なら、それを見せてください。 System.DataとCoreFXに関して私が見ているのは、「MSが必要としていること、他のすべての人が必要としていることは、バックバーナーにあるか無視されている」ということだけです。

私が言及するのを忘れたもう一つのこと：ファウラーは昨日ツイッターであなたが彼らのものを移植するために皆が必要であると述べました。 500K LoCコードベースをCoreFXに移植するために自分でお金を払わなければなりません。時間と労力がかかり、他の機能のために時間がかかります。 完全に人工的な余分な摩擦（これは新しいプラットフォームです！どのように制限ルールがあるのでしょうか？）は実際にはまったく役に立ちません。余分なメンテナンスコストが追加され、コードの移植とテストに余分な時間がかかり、ユーザーに余分な負担がかかります。

それはすべてあなたの範囲外であり、あなたの懸念ではないようです。 しかし、あなたは1つのことを忘れています。それは、コードを移植せず、私と一緒にもっと多くの人を移植しない場合はどうなるでしょうか。 私は時間と自分のお金を投資して、私の大きなコードベースを新しい光沢のあるフレームワークに移植したいと思っていますが、問題が発生したときはいつでも、制限、奇妙なルール、そして沈黙で終わる無限の議論に遭遇します。 。 Iow：私は非常に孤独を感じていますが、同時にあなたは私たちにあなたの新しい光沢のあるフレームワークを好きになりたいと切実に望んでいるようです。

ずっと前に言ったように：このフレームワーク、この新しいCoreFXを売ってください。 まあ、摩擦を維持し、移動して持ち去ったチーズをたくさん導入することは、これに多くの時間（とお金）を投資する大きなインセンティブを生み出していません。

ちょうど私の2セント。

@FransBoumaこの会話を専門的で生産的で、事実に焦点を合わせて維持してみましょう。

私はインターフェースの追加に賛成または反対しているわけではありません。 ただし、インターフェイスにメソッドを追加することには互換性がありません。 これを見ていきましょう：

1）IDbConnection.OpenAsyncを.NETCoreに追加します
2）このメソッドを呼び出すと、.NET Frameworkでの実行に失敗します（上記で呼び出したコア原則/目標を破ります）。 これは、XAMLデザイナとこの事実に依存する他のいくつかのVS機能も壊します。
3）.NET Frameworkを最新の状態にするために、IDbConnection.OpenAsyncを備えた新しいバージョンの.NET Framework "4.7"を出荷します。
4）このメソッドを追加する前にIDbConnectionを実装したすべてのタイプは、.NET Framework "4.7"でのロードに失敗するようになりました。

これが、インターフェイスにメソッドを追加できない理由です。

MSとの問題を自分自身に伝えることに関して物事がどうなるかについて不満を抱き続けると、皆さんはそれについて知らず、すべてがバラと虹だと思います。 それが専門家ではないように見える場合は、それでも、MSが私を専門家だと思っているかどうかは気になりません。

つまり、私はインターフェイスと結婚していないので、インターフェイスがなくなったとしても、理論的にはクラスがあり、インターフェイスを使用できないという事実は、私を悲しいパンダにすることはありません。今日では、すべての主要なADO.NETプロバイダーがうまく機能し、基本クラスから派生しているため、理論的には基本クラスでも実行されます（これは、ODP.NETがインターフェイスを実装している過去のIIRCには当てはまりませんでしたが、そうではありませんでした。基本クラスから派生）。 これは、私がこのスレッドの前半で最初にそれらを削除することが大したことだとは本当に思っていなかった理由でもあります。 それ以来、私はそれについて考える時間がありました、そしてそれは大したことだと思います。

私たちは火星に住んでおらず、スタックの最下部にあるミドルウェア/フレームワークに問題があります。これらのフレームワークの現在の.NETフルバージョンのユーザーは、これらのフレームワークを知っている

その理由だけで、私はインターフェースを元に戻したいと思います。 私にとっては、技術的な理由ではありません（たとえば、非同期には基本クラスが必要ですが、すでに混乱しています）。 私は彼らが特定の方法を欠いていることを知っています、しかしそれはあなたの問題であり、私の問題ではありません。 それらを削除すると、それが私の問題になり、（今言い換えると）それに対するMSの応答は次のようになります。「できません！」と手を挙げてください。 しかし、私にはそのような贅沢はありません。 あなたはこの混乱を作成しました、あなたはそれを解決します。 あなたは私に私のコードを移植して、あなたの新しいフレームワークをサポートするために多くの時間とお金（私は自分で払わなければならない）を投資することを望んでいます、なぜあなたはあなたの問題を私の問題にしているのですか？

4ステップのシナリオを見ると、CoreFXを別個のフレームワークと見なす場合、インターフェイスにメソッドを追加することは問題ではありません。 とにかくそうではありませんか？ これは、何年も前のCompact Frameworkの場合と同じです（フレームワークを移植しました。その後、CoreFXへの移植は単純、高速、簡単ではなく、2つのコードベースを維持することはできないという難しい教訓をいくつか学びました。どちらでもない）：1つのAPIから始めて、誰かが何かを忘れたか、MS内のチームが何かを必要とし、ビオラの重大な変更は、ほんの一握りの低レベルのスタック開発者だけが遭遇するなど、2つの道が分かれます。

（例：Compact Frameworkは「SerializableAttribute」を忘れました。後のバージョンではダミー属性が何もしないことを追加しましたが、それが存在しないことを予期し、独自に定義したコードを壊しました）

ただし、道路を分割することは理解できます。互換性を維持しようとすることは制限が厳しすぎます。 私はここで、このルールが将来破られることを予測しています。

物事を「互換性がある」と見なすことは、APIシグネチャレベルだけでなく、API_behavior_レベルでも重要です。 APIの動作でこれら2つが完全に同じ（CoreFXと.NET Full）になると信頼するのはリスクが高すぎます。フレームワーク開発者はCoreFXと.NET fullで同じ機能をテストする必要があり、CoreFXだけでテストする方法はありません。将来、コードが.NETで100％同じように機能すると想定するのに十分です。どうすればそれを保証できるのでしょうか。 CoreFXの深部にあるコールスタック20の呼び出しは、.NETフル以外の多くのコードに影響を与えており、細部が所々にあり、状況が変化しています。

このすべてのポイントは次のとおりです。これは別個のフレームワークです。CoreFXに対してコンパイルされたコードは、.NETfullに対してコンパイルされたコードとは異なることが予想されます。

いくつかの状況があります：

1）フレームワークには、CoreFXで100％コンパイルされるコードベースがあります。 これにより、.NETフルで実行可能なdllが提供されます。
2）フレームワークにはコードベースがあり、その70％はCoreFXでコンパイルされ、100％は.NETフルでコンパイルされます。 これにより、2つのdllが提供されます。1つはCoreFX用で、もう1つは.NETフル用です。 機能の30％を見逃しているため、.NETでCoreFXバージョンを完全に実行するのはばかげています。

1）の場合あなたの主張は理解できます。 2）の場合（これは、現在のすべての.NETフルターゲティングフレームワークの場合であり、その中には_all_サードパーティORMが含まれます）、とにかく2つのdllを処理する必要があるため、ポイントは本当に無意味です。個別に保守し、個別にテストし、個別に新しいバージョンに移行します。 特に、CoreFXが.NETの一部ではない新機能を取得した場合（これはそうなるでしょう）。 （ところで、DataTableとは異なるデータ構造を返すCoreFXにDbDataReader.GetSchemaTable（）を追加すると、MSはそれを移植することを拒否するため、CoreFXでDbDataReader.GetSchemaTableを使用するコードは.NETフルでも壊れます。別の名前を付けるとメソッドが存在しないだけでなく、壊れます。Iow：_both_フレームワークにないものが使用されると、コードが壊れます。したがって、CoreFXに存在してはならないという意味ではありません）。

CoreFXにインターフェイスがない場合、状況2）のフレームワークの状況が永続的になります。たとえば、APIがインターフェイスを公開するため、1）に適合するフレームワークになるために移動することはできません。

マイクロソフトが独自のものを書き直して、フレームワークが状況1）のフレームワークになるようにするのはクールですが、100万ドルの予算はなく、ORMランタイムに15人以上の人員がいて、私たちの側には大きなPRマシンがあります。そこにあるすべてのアプリを壊します。 したがって、2）で立ち往生しているか、1）に移行するためにMSからの少しの助けが必要です。

それがここで危機に瀕していることです。 あなたはツイッターで「必要なものを教えてください」と言った。 しました。 繰り返し。 特にSystem.Dataに関しては通信がありません。 何もない。 将来の計画も、何をすべきかについての議論もありません。行き止まりであり、MSの人が介入した場合、その問題に実質的な利害関係がない場合もあります。 これについてお時間をいただきありがとうございます。背景が多ければ多いほど良くなりますが、同時に、これについて同僚と話しているようなものです。担当者が不在であり、そうではないため、解決されません。議論に参加する。

それが私を苛立たせ、神が「専門家ではない」ことを禁じているように聞こえるなら、そうです。

聞いてくれてありがとう。 ところで、System.Dataについては幻想はありません。コードを移植するためのAPIの難破であり、APIの上に主要なフレームワークを作成する開発者との担当者からの連絡がないため、希望はほとんどありません。変更されます。 あなたのせいではありません、 @ davkean 、それは個人的なことではありません。

私はコミュニケーションの欠如についての上記の欲求不満をエコーし​​なければなりません。 一括挿入とスキーマ情報も必要です。 これらの欠落しているコア（両方の方法）機能の進歩または通信は、1か月以上（dotnet / runtime＃15269およびdotnet / runtime＃14302を参照）ありませんでした。 それでも、Microsoftは現在のコードを「リリースの候補」としてラベル付けしており、それ自体が「十分に良い」というメッセージです。 そうではありません。 追加する必要のあるコアなものが欠落しており、これらのスレッドに従う場合は、同様のバージョン管理の理由で最初のバージョンにする必要があります。

dotnet / runtime＃14302の最後の更新（「DataTable / View / Setが存在しないのはなぜですか？」）を見てください。22日前からの質問です。

では、System.Data.Commonは、CoreCLRのV1の機能が完了したのでしょうか。

はい、欲求不満は専門家ではないとして外れる可能性があります。 テキストのトーンとコンテキストはひどく、常にありますが、それがここで制限されていることです。 誰もがここで生産性を発揮しようとしていると思いますが、 System.Data領域での実際の進捗状況について、CoreFX側からかなりの障害が発生しています。つまり、率直に言って、図書館の著者として両方を激怒させています。そしてこれらのビットのユーザー。

これらのコア機能部分、インターフェースが必要かどうか-私はインターフェースに固執しているわけではなく、それらなしでDapperを移植しました。 ただし、DataTable、結果スキーマ情報、一括挿入などの欠如は、「リリース候補」では受け入れられません。 マイクロソフトは、リリースの準備ができていないことがほぼ普遍的に合意されているときに、現在のコードをRCとしてラベル付けすることへの不満を増大させている企業です。 はい、それは単なるラベルですが、それは間違ったラベルであり、任意のスケジュール（現実を反映するために変更されるべきでした）に基づいているため、緊急性のレベルを大幅に高めるものです。 このスレッドの誰もがそのスケジュールに責任があるとは思いませんが、フラストレーションの主な要因として述べる価値があります_レベル_。

根本的な問題に戻りましょう。 これらの要素が必要であり、何百万ものユーザーの多くが必要としています。 それでは修正しましょう。

100万回以上のダウンロードでNHibernateを忘れないでください：

| IDbConnection | IDbCommand | IDataReader |
| --- | --- | --- |
| 59 | 181 | 132 |

現在の認識では、ADO.NET / CoreCLRは、EFとSQL Serverのファーストクラスのサポートを提供するように再設計されており、残りのエコシステムは無視されています。このような不透明な決定は、このステレオタイプを強化するためだけに行われます。 。

その認識は次のようなものによって強化されます： //github.com/dotnet/corefx/issues/4646

私の知る限り、SqlClientアセンブリの外部でそのAPIを便利な方法で実装する方法はありません。

私は現在、インターフェースなしのテストで大丈夫です。 しかし、正直なところ、インターフェイスのバージョン管理と互換性については理由がわかりません。

.NET Coreのアイデアは、互換性の負担がない新しいフレームワークであり、アプリケーションにバンドルされているため、そのような問題に対処する必要がないということではありませんか？ スキーマやデータテーブルなどが不足しているため、プロバイダーはすでに.NETのプロバイダーと互換性がありません。では、互換性を損なうものは何でしょうか。 インターフェースが変更された場合は、新しいバージョンに対してコンパイルして、アプリにバンドルするだけです。

デザインの言い訳のほとんどは、新しいフレームワークには適用できない古いフレームワークからの心配であるように思えます。 とにかく、それが実際にどのようになっているのか見てみましょう。

複数のフレームワークをサポートすることを意図し、歴史的にインターフェースをターゲットにしてきた使用者のために... Dapperが使用する醜い山を共有したいだけです。 これが_良い_と言っているわけではありませんが、コンパイルするには十分です。 もちろん、それは膨大な数のファイルに複製されています...私は主にこれを共有して、さらに別の影響を強調しています。

https://github.com/StackExchange/dapper-dot-net/blob/master/Dapper/SqlMapper.cs#L6 -L16

インターフェイスにメンバーを追加できません

正解です。これはインターフェースの_優れた_機能です。 抽象基本クラスを優先することは、APIエントロピーと戦うのではなく、APIエントロピーを支援する最も安全な方法です。

OODのは従うことをお勧めします。 要するに、インターフェイス分離の原則（ISP）は、_クライアントが使用しないメソッドに依存することを強制されるべきではない_と述べています。

既存の抽象化に新しいメソッドを追加すると、自動的にISPに違反します。

あなたはマイクロソフトであり、BCLを使用しているため、「SOLIDに準拠する必要はない」と判断できます。したがって、「通常のルールは適用されません」（実際の見積もりではなく、通常のルールを言い換えるだけです）。反論）。

いくつかのオープンソースプロジェクトを6〜7年間維持してきたので、私の経験では、インターフェイスを小さく保つ方がよいでしょう。 抽象化に新しい機能を追加する必要がある場合は、新しいインターフェースを導入してください。

• 「実装ではなく、インターフェースへのプログラム。 」
• 「クラス継承よりもオブジェクトコンポジションを優先します。 」

ここに賛成票があったら、@ ploehのコメント+1000に

いつものように@ploehからの洞察に

@FransBouma 、完全なフレームワークを壊さない方法でDbDataReader.GetSchemaTable（）の置換機能を追加します。
@ NickCraver 、SqlBulkCopyは将来の計画にあり、スキーマに取り組んでいます。 x-platformでスタックを機能させるためにも合理的な進歩を遂げる必要があるため、スキーマの進歩は遅いです。
@mythz 、顧客への影響に関する例、数値、および評価を提供していただきありがとう

@YoungGah情報に関連する問題を更新して、これらの問題が最新の状態に保たれるようにしてください（例： //github.com/dotnet/corefx/issues/1039 ）。そうしないと、まばらな情報がいたるところに散らばります。 GetSchemaTableを追加するのは良いことです（そしてDbConnectionの同等のもの、それを忘れないでください！）が、何が起こるか、そして_いつ_かについての情報を得るのはとても難しいです。 いつ追加される予定はありますか？ 私たちが今続けなければならないのは、「将来」に何かが追加されるかもしれないというヒントです。 正直なところ、これはコードベースの移植を計画するのにあまり適していません。

@FransBouma 、はい、他のスレッドも更新します。 何がいつ利用可能になるかについての詳細についてのあなたの要求に関しては、私はあなたたちがそれを必要とする理由を完全に理解しています。 機能/機能がv1で利用可能になるか、意図的に削除されるか、v1以降で利用可能になるか、または将来の利用可能性の設計が保留されているかを示すリストを公開します。 次の2週間で投稿しようと思います。 DbDataReaderのgetschema関数とDbConnection関数については、rc2リリースで利用できるようにする予定です。 予期せぬ理由で計画が変更された場合は、コミュニティを更新します。

ここで何が起こるか、そして将来の参考のために@YoungGah; IDataReaderはDataTableに依存しており、DataSetに依存しています（これは別のレイヤーと見なされます-ポリシーがないこれらのタイプとは異なり、ポリシーが重いため）。持ち帰った。

@ploehのアプローチについて、ここで別の投票を@davkeanのコメントと、バージョン管理への対処の両方を

古いインターフェースを継承する新しいインターフェースを作成できないのはなぜですか。 古いものは廃止されました。 将来的に古いものを削除します。 少なくとも、それを拡張して、既存の用途を壊さないようにすることができます。

または複数の小さなインターフェース。 コメントをお願いします。

元の.NETと完全に互換性がある必要があることを理解していません。 ここで壊すものは何もありません。これは新しいフレームワークであり、レガシーコードとの関係を断ち切り、長い間必要であるが元のフレームワークでは傷つく変更を適用する絶好の機会です。

インターフェイスを提案したとき、元の1.1インターフェイスを戻すことは考えていませんでしたが、新しいデザインでインターフェイスを更新しました。 @ploehが言ったように、それらはさらに多くなる可能性があります。

インターフェースはい、可能であればレガシーサポートですが、現時点では優先すべきではありません。

このトピックに多くの関心があるので再開します。

ここで壊すものは何もありません。これは新しいフレームワークであり、レガシーコードとの関係を断ち切り、長い間必要であるが元のフレームワークでは傷つく変更を適用する絶好の機会です。

では、元の不適切に設計されたインターフェイスを取り除き、ADO.NETのような基本クラスで標準化する絶好の機会はすでに行われているのでしょうか。 ：ドヤ顔：

ただし、真剣に、クリーンなAPIまたは下位互換性のどちらかを選択できます。 一つを選ぶ。 私はあなたのケーキを持ってそれを食べる方法がわかりません。

@JamesNKですが、まさにそれがポイントです。 下位互換性は必要ありません、期間。

冗談ですが、インターフェイスを使用したAPIの設計が不適切だったのは、インターフェイスであるためではなく、設計が不適切だったためです。 =）インターフェースがNETのどこでも絶対に使用されていないわけではなく、これは何か新しいことです。 今回は正しく設計して先に進んでください。

ADO.NETは、すべての.NETで最も安定したコードの1つです。 15年間で2、3回の重大な変化がありました。 これは、インターフェースに安定し、誰にとってもシンプルにするのに最適なAPIです。

注意として、ここでのでもあり、インターフェースと仮想メソッド、テスト容易性などについて同じ長い議論がありました。

@nvivo認めなければなりません、私は混乱しています。 基本クラスがテスト容易性を有効にすることを確立した後、このスレッドは、.NETFrameworkコードを.NETCoreに移植できるようにするためにインターフェースを戻すように変形しました。 インターフェイスを再設計し、何か新しいものを導入することは、どのように役立ちますか？

下位互換性のために元のインターフェースを用意して、選択したもの（抽象クラ​​スまたは小さなインターフェース）を先に進めることができないのはなぜですか？ 元のインターフェイスは新しいスタックの上に配置され、下位互換性を提供できます。 この部分もオプションである可能性があります。
これにより、移植が簡単になり、新しい方法が可能になります。

@davkean

ここにコメントしたすべての人に返信することはできません。 ADO.NETのAPIとしてインターフェイスを使用することを提案し、新しい現在のAPIに更新しました。 私は元のインターフェースとそれが持っていたすべての問題を持ってくるように頼みませんでした。 目的は、よりクリーンに定義されたAPIを用意し、それをモックして、それに依存するコード（主にユーザーコードではなくデータ抽象化ライブラリ）をテストすることを容易にすることでした。

@ploehが賢明に言ったように、インターフェースはAPIの記述に優れており、モックを作成するのは

ここで、クラスがすでに悪い設計をどのように作成しているかを確認するだけです。

• DbCommandにDesignTimeVisibleプロパティがあるのはなぜですか？ 設計時のサポートは、接続を接続とし​​て定義するための要件ですか？
• 状態の変化を
• ConnectionStringBuilderは、プロバイダーが存在するための要件ですか？ それとも、VSウィザードをそのまま使用できるようにするための優れた点はありますか？
• DbDataReaderが一部のコアタイプに対してGetメソッドを定義しているのに、 GetByteArray()やGetDateTimeOffset()などの他のタイプには追加されていないのGetDateTimeOffset()なぜですか？ また、文字列またはストリームを使用して外部で実行できる場合でもGetSql*ファミリーなど）の拡張メソッドまたはヘルパーとして作成されますか？

これらはすべて修辞的な質問です。 それらのすべてが説得力のある答えを持っており、物事が考慮されていると確信しています。 重要なのは、現在の設計は明らかにAPI定義として考えられていたものではなく、おそらくインターフェースでより注目さ

正直なところ、外部からの設計の議論は次のように聞こえます。

• Visual Studioのウィザードが箱から出して作業する方が簡単なので、これらのイベントをここに保持しましょう。
• EFがあるので、スキーマ検索メソッドを削除しましょう。これは、世界中の誰もが使用する必要がある期間です。
• これらの便利なメソッドは.NET1.1以降でサポートされており、互換性を壊すことはできないため、そのままにしておきましょう。
• データテーブルとデータセットを削除して、.NET1.1からのすべてのユーザーにコードベース全体を変更させましょう。
• クラウドコンピューティング、コミュニティ、オープンソース、そして明日のアプリケーションに焦点を当てた新しいプロバイダーモデルを構築しましょう...
• ...そして、昨日のニーズに基づいて、SqlClientを_sole_テストケースとして使用してこのモデルを構築しましょう！
• 各アプリケーションにバンドルされるまったく新しいフレームワークを構築しましょう。そうすれば、更新によってアプリケーションが壊れる心配はありません。
• ..次に、変更によって更新が破損する可能性があるため、インターフェイスを追加しないことを決定しましょう。

はい、そこには少し怒りがあり、この議論はどこにも行きません=）...しかし、これを私の胸から取り出したかっただけです。 2015年ですが、すべてが常に壊れており、私たちはそれに慣れています。 今後数年間でASP.NETMVCに20の更新があり、ADO.NETのインターフェイスの変更よりもはるかに多くの重大な変更が発生します。

私はまだ.NETが大好きで、あなたがそれを使って一般的に行っていることは、.NET Core v1を間に合わせるのは急いでいると確信しており、すべてが完璧になるわけではありません。 時間が経つにつれ、コミュニティがこれを他の方向に導く手助けをしてくれることを願っています。私たちが移動するときに物事を壊すことを恐れないでください。

ORMメンテナにとって、なぜそうしないのですか？

`` `c＃

COREFXの場合

名前空間System.Data {
パブリックインターフェイスIDbConnection {...}
}
`` `

アダプターパターンを使用して、新しいSystem.Dataを独自の実装でラップしますか？ 実際、そのためのオープンソースコードパッケージを作成して共有することができます。

It's 2015, everything breaks all the time and we're used to it. There will be 20 updates to ASP.NET MVC in the next years that will cause a lot more breaking changes than interface changes in ADO.NET.

I still love .NET and what you're doing with it in general, I'm sure it's a rush to get .NET Core v1 out in time and not everything will be perfect. I just hope the community can help steer this to other directions as the time goes and you're not afraid to break things as we move.
- nvivo

これが問題です; 検討されたアプローチではなく、任意の期限に間に合わせるために急いで書き直しを行っています。
光沢のある新しい壊れたがらくたを持っているよりも、必要に応じて2016年第4四半期に遅くなりました。 それは2015年であり、すべてが壊れることはひどい正当化です。

@thefringeninjaは、システムの半分（共有の場合）でのみ機能する完全に不要で紛らわしい依存関係を追加するか、名前の衝突につながり、選択を解除するためにextern aliasを必要とします（そして、なぜSystem.Data.IDbConnectionは、提供しているものとは異なるが同じSystem.Data.IDbConnectionを受け入れません）。 基本的に、それは事態を10倍悪化させるでしょう。

@mgravellの具体例をType.GetType("System.Data.IDbConnection, System.Data")を使用した場合、またはPCLシナリオで使用した場合、これがどのように機能するかがわかります。

orm AがSystem.Data.IDbConnectionを定義し、ormBが定義する場合
System.Data.IDbConnectionの場合、2つの完全に異なるものがあります。
同じ名前/名前空間、競合、および
どのDBプロバイダーからも実際には機能しません。 それは何も解決しません、
基本的。 さらに悪いことに、誰かが合格することを期待している使用できないAPIにリースします
SqlConnectionまたはNgpSqlConnectionで-そしてそれは機能しません。

実際、そのためのオープンソースコードパッケージを作成して共有することができます。

System.Data.Commonでない場合は、DbConnectionがそれを実装していないことを意味します。：気にしない方がよいでしょう。

すべてのORMまたはADO.NETプロバイダーのメンテナが外部のサードパーティの依存関係を引き継ぐことについてコンセンサスを得ることができず（SQL Serverがほとんど保証しない）、コアBCLインターフェイスを再定義する2つのライブラリを一緒に使用することはできません。 コアライブラリのSystem.Dataインターフェイスを参照する高レベルのフレームワーク（ServiceStackなど）の場合はさらに悪いことに、同じインターフェイスを参照しなかったORMを使用できなくなります。 -1つはそうするかすべきです。

すべてのライブラリが同じSystem.Dataインターフェイスを参照するようにする唯一の方法は、それらを実装する基本クラスで復元された場合です。これがどのような害を及ぼすかはまだわかりません。

@mgravellああ推移的な依存関係、それを考慮していませんでした。 ：+1：

コードを所有していないコードに緊密に結合しない限り、これが問題になる理由がわかりません。 コードを依存関係から保護してください！ それをまとめて抽象化します。 これを実行してコードをテスト可能にする方法はたくさんあります。 多くは上で言及されています。 所有していないビットを統合テストします。 それが機能する方法です。 BCLオブジェクトをあざけるべきではありません！ あなたがそうなら、あなたのデザインは良くありません。

@nvivoこれは元の問題だと思いますが、互換性の理由から、v1時代のインターフェイスを復活させることについての方向性がスレッドになりました。 それに焦点を合わせ続けましょう-現在の表面積に変更を加えることについて話し合いたい場合は、新しい問題を提出してください。

@mythzインターフェースに関して2つの問題がありました。 1）ポリシーフリーの抽象化に属さないDataSetへの（重い）依存関係をもたらしました。2）基本クラスに並列の抽象化セットをもたらしましたが、v1表面積でロックされています。 その混乱を避けたかったのです。

私は、サードパーティがこれらのインターフェースを提供することは実行可能ではないことに同意します-それらは有用であるためにコア抽象化に実装される必要があります。

これは元々の問題だと思いますが、互換性の理由から、v1時代のインターフェースを復活させることについての方向性がスレッドになりました。 それに焦点を合わせ続けましょう-現在の表面積に変更を加えることについて話し合いたい場合は、新しい問題を提出してください。

これはまったく意味がありません。

@nvivoは、それを提出したにもかかわらず、あなたは問題を抱えている人ではないことを意味します-それを閉じたことから明らかです。 問題は、System.Dataインターフェースを復元して、それらに依存しているエコシステム全体をサポートする負担を軽減することです。 あなたは大丈夫のようです：

2015年ですが、すべてが常に壊れており、私たちはそれに慣れています。

しかし、これは、既存のコードベースとお客様のコードベースをサポートする必要がある私たちにとって満足のいく戦略ではなく、すべての.NETに影響を与えるBCLライブラリの管理者にとってデフォルトの戦略であってはなりません。

しかし、これは既存のコードベースをサポートしなければならない私たちにとって満足のいく戦略ではありません

@mythzこれは文脈から外れています。 そういう意味じゃない。 ここのEvertybodyは、既存のコードベースをサポートする必要があります。議論の中で.NETに新しい人がいるのではないかと思います。

この会話がどのように変わったかという問題は、それがあまり意味をなさないということです。 .NET Coreは新しいフレームワークであり、アップグレードではありません。 既存の完全な.NETAPIの多くは存在せず、存在しません。 とにかく、下位互換性はそのようには機能しません。

@nvivoこの正確な感情が、この問題が当てはまらない理由です。 下位互換性が重要でないと思われる場合は、複数のプラットフォームを対象とした意味のあるコードベースをサポートしようとしたことはありません。CoreCLRチームを代表して話しているわけでもありません。 これらのライブラリは最初から開発されたものではありません。上記を読むと、CoreCLRライブラリを完全な.NETFrameworkで実行することが主な目標であることがわかります。 CoreCLRは、既存のライブラリの移植が成功に不可欠なもう1つのプラットフォームターゲットであり、.NETチームが積極的に奨励しており、これらの欠落しているインターフェイスが現在妨げているものです。

インターフェイスがバージョンフレンドリーではないというこのすべての話で、Goプログラミング言語が暗黙のインターフェイスでこの問題をどのように回避するかについて考えさせられます。

_policy-free_abstractionsの意味を詳しく説明するように求められました。

基本的に、ポリシーフリーとは、System.Data.Commonの抽象化に含まれるビジネスルールがほとんどないことを意味します。つまり、特定のプロバイダーが実装する必要のあるAPIの形状を提供するだけです。 これは、多くのビジネスルールとコードがあるDataSetとは対照的です。 ポリシーフリータイプは、その構造自体が原因で、ポリシーを含むタイプよりもバージョン管理の頻度が低くなる傾向があります。これは、コードが少なく、バグや設計変更が少ないためです。 大規模なパッケージグラフ全体で依存関係を調整するときに発生する問題の数を減らすために、サードパーティライブラリ間で_交換される_ [1]バージョンの頻度が低い[2]抽象化と型が必要です。 アプリケーションの一部として交換タイプを埋め込んだり、ilmergeしたりすることはできませんが、非交換タイプはできます。 したがって、なぜそれらを分割したいのですか。

[1] _exchanged_とは、パブリックAPIに表示される傾向のあるタイプを意味します。 たとえば、 Collection<T>は交換タイプと見なされますが、 List<T>は考慮されません。
[2]これらにセマンティックバージョニングを使用すると、エコシステムを「フォーク」するため、削除されたインターフェイスで上記とほぼ同じブレークが発生します。 ライブラリは、ブレークの前または後にライブラリをターゲットにするか、分割を処理するために自分自身をフォークするかを決定する必要があります。

@mythz商用アプリと既存のコードの一部としてorms / customersをサポートする必要があります...どちらの側にも同意するとは言いませんが、実際のところ、dnxは完全に新しいフレームワーク/ランタイムです。 いくつかのインターフェースがない場合は、コンパイラ指令を使用して処理します。

いくつかのインターフェースがない場合は、コンパイラ指令を使用して処理します。

おお？ IDataReaderを返すメソッド、またはIDbConnectionを受け入れるメソッドはどうですか？ またはIDbTransaction？ _customers_コードがそのAPIを使用している場合、その周りで#ifdevをどのように実行しますか？

「それに対処する」...それはどのような傲慢ですか？

シンプルで、基盤となるパッケージ（組織）を更新して、2.0以降でサポートされている独自のタイプまたは基本タイプを返します。 古いバージョンの.netをターゲットにしている場合は、代わりにディレクティブを使用してインターフェイスを返し、非推奨としてマークすることができます。

はい、それはひどいことですが、彼ら（これについて常に考えている本当に賢い個人）が当時（.net 2.0に戻って）正当な理由でそれをしたと確信しています。 話が起こる可能性があり、おそらくこれは確実に変更されます。しかし、問題の事実は、新しいランタイムにアップグレードする人々がいくつかの作業をしなければならないということです。 派手なUIのボタンをクリックするのではなく、それらの作業を切り取ってもらいます。しかし同時に、新しいフレームワークへのアップグレードは、多数のタイプを置き換えて置き換えるよりも簡単である必要があることに同意します。

@FransBouma彼はおそらく強いネーミングも提唱している人です。

@FransBouma @ phillip-haydonはあなたのトローリングを他の場所に連れて行くことができます、あなたはそのように行動することを期待することはできません、そして人々はあなたを真剣に受け止めます。 疑問がある場合は、関係する私のオープンソースの貢献/プロジェクトを見てください...私はこれに対処する必要があります...どちらの方法でも...

記録のために、私は強い命名に反対しています。

それに対処する...

そして、あなたは私がトローリングしていると言いますか？

「 @FransBouma彼はおそらく強いネーミングも提唱している人です。」 トピックから外れていて、この話にはあまり役に立ちません。 はい、それはあなたのトローリングのように感じます。

この説明で考慮すべき重要な事実の1つは、基本クラスが導入された10年前に.NET2.0でIDb *インターフェイスがADO.NETのAPIとして非推奨になったということです。 それらは非推奨とはマークされていませんが、それ以降に構築されたものはすべて、代わりに基本クラスに依存します。 App.configプロバイダーと接続文字列のサポートが思い浮かびます。

これらのインターフェースに依存するコードがある場合は、非同期メソッドなどをサポートしていない非常に古いAPIに対してコーディングしているため、他のユーザーに引き続き使用してもらいたい場合は、とにかく更新する必要があります。

シンプルで、基盤となるパッケージ（組織）を更新して、2.0以降でサポートされている独自のタイプまたは基本タイプを返します。 古いバージョンの.netをターゲットにしている場合は、代わりにディレクティブを使用してインターフェイスを返し、非推奨としてマークすることができます。

これはパブリックAPIであり、何千ものアプリケーションで使用されています。APIはパブリックであり、.net1.0以降で使用されています。 それどころか、それは「単純」ではありません。 APIを変更するだけでは不十分です。マイクロソフトは、それが私たちの生活をより良くするために彼らがしなければならないことだと考えているからです。それはユーザーにとって、したがって私たちにとって大きな負担になるでしょう。

はい、それはひどいことですが、彼ら（これについて常に考えている本当に賢い個人）が当時（.net 2.0に戻って）正当な理由でそれをしたと確信しています。 話が起こる可能性があり、おそらくこれは確実に変更されます。しかし、問題の事実は、新しいランタイムにアップグレードする人々がいくつかの作業をしなければならないということです。 派手なUIのボタンをクリックするのではなく、それらの作業を切り取ってもらいます。しかし同時に、新しいフレームワークへのアップグレードは、多数のタイプを置き換えて置き換えるよりも簡単である必要があることに同意します。

それが問題です。「新しいランタイム」とは見なされません。 もしそうなら、私がすでに議論したように、それは問題ではないでしょう。 ただし、Microsoftは、CoreFXターゲティングdllが.NETでも完全に機能する必要があるという考えを持っているため、新しいフレームワークはありません。 CoreFXにない機能を備えた.NETフルを対象とするライブラリのメンテナにとっても（今日の多くのライブラリは）、2つのバージョンを維持する必要があるため、多くの「楽しみ」があります。 2つまたは3つの#ifdevsではなく、問題は解決されていますが、それらの多くは解決されています。 APIの変更に費やす必要のある時間についてクライアントに請求できるため、おそらくそれはあなたにとっては異なります。 多くの人が使用する汎用システムを作成する場合は異なります。

コンパクトなフレームワークのサポートがガイドラインである場合、完全な.netとCoreCLRでORMをサポートすることは、ひどい時間の浪費であり、多くのフラストレーションがあり、実際にはあまり得られません。新しい機能は得られず、それらの「欠如」を回避するだけです。 。

（そして誰かが始める前に：「しかしそれはLinux上で実行されます、あなたはそれを得るでしょう」：私たちのものは何年もの間Mono上で実行されます。

SellMeThisFramework。 ああ、なぜ私も気にしています。

しかし、それ以降に構築されたものはすべて、代わりに基本クラスに依存します

_cough_ Linq-to-SQL DataContext _cough_

実際、多くの非MS ORMを実行するので、問題が発生します。 ダッパーの場合は少しだけ
弾丸とDbConnectionに移行しました。 もう一度時間があったら、私は
MSが何かを廃止する場合は、[廃止]を使用することを強くお勧めします。 しかし：
過去を変えることはできません。

ただし、特にほとんどの場合、解決するのは非常に苦痛な問題です。
ライブラリの作成者は、両方のAPIを続行する必要があります（
net40など、およびDNXの別の方法）。 私は以前に恐ろしい混乱を投稿しました
そのdapperはこれを行うために使用します：それはきれいではなく、それはそれほど単純ではありません

もしも。

2015年11月27日20:07、「NatanVivo」 [email protected]は次のように書いています。

この議論で考慮すべき重要な事実の1つは、IDb *が
インターフェイスは、10年前に.NET2.0でADO.NETのAPIとして非推奨になりました
基本クラスが導入されたとき。 非推奨とはマークされていませんが、
それ以降に構築されたものはすべて、代わりに基本クラスに依存します。
App.configプロバイダーと接続文字列のサポートが思い浮かびます。

これらのインターフェースに依存するコードがある場合は、
非同期メソッドのようなものをサポートしていない非常に時代遅れのAPI、つまり
人々にそれを使い続けてもらいたいのなら、とにかくそれを更新する必要があるでしょう。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/dotnet/corefx/issues/3480#issuecomment-160198453 。

インターフェイスを使用した結果、非同期メソッドを追加できなかったという点がわかりません。 非同期メソッド用の新しいインターフェースを作成することもできます。 IAsyncDbCommand 、 IAsyncDataReaderなど。次に、基本クラスに両方のタイプのインターフェースを実装させることができます。

ADO.NETユーザーは、非同期バージョンまたは同期バージョンのいずれかを使用していますが、両方を使用しているわけではありません。 だからそれはうまくいっただろう。

ライブラリ開発者にとって、機能が拡張され、インターフェイスが同じままであるかどうかは実際には問題ではありません。 それが目的ではありませんか？ 新しい機能のための新しいインターフェースを導入します。 基本クラスでの作業はただの苦痛です。

ここでスレッドを要約できますか？

.NETデータツールに関する複数の独立した認められたコミュニティの専門家、
複数のORM作成者とメンテナを含むことはあなたに言っています-かなり
明らかに-これは重大な問題のセットを表していること。 私は思わない
私たちの誰もが微妙なことを知らない、またはプログラミングにナイーブです
原則、そして私たち全員ではないにしてもほとんどの人が裏話のすべてをうまく知っています、
当時そこにいたからです。

公式の回答は「私たちには問題ないようで、EFは満足している」と思われます。
はい、私たちはそれを知っています、なぜなら決定はそもそもなされたからです。

まあ、実りがなくても、みんなで意見を述べてきました。
2015年11月27日20:41、「JonasGauffin」 [email protected]は次のように書いています。

非同期メソッドを追加できなかったという点がわかりません。
インターフェイスを使用した結果。 のための_新しい_インターフェースを作成することができます
非同期メソッド。 IAsyncDbCommand、IAsyncDataReaderなど。
基本クラスに両方のタイプのインターフェースを実装させます。

ADO.NETユーザーは、非同期バージョンまたは同期バージョンのいずれかを使用しています
バージョン、両方ではありません。 だからそれはうまくいっただろう。

ライブラリ開発者にとって、機能が拡張され、
インターフェイスは同じままです。 それが目的ではありませんか？ 新しいを紹介します
新機能のためのインターフェース。 基本クラスでの作業はただの苦痛です。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/dotnet/corefx/issues/3480#issuecomment-160201361 。

おい..コードを更新してメジャーバージョンをバンプします。 終わり。

はい。ただし、コアをターゲットにするときに、コンパイラ指令でそのインターフェイスをポーリングできなかった理由はありません。 私はいくつかのpclパッケージでそれを行いました。

マイクロソフトは、コアがドットネットでいっぱいではないことを繰り返す必要があると思いますが、それでも役に立ちません。正直に言うと、マイクロソフトはいくつかのインターフェイスをクリーンアップする必要があると思います。 最近、非常に一貫性のないインターフェイスがあり、どれを選択すればよいかわからないというブログ投稿がありました。2番目の非同期インターフェイスを定義するのは面倒だと思います。 すべてが非同期だったらいいのに。

非推奨としてマークする必要があるものが...そして4.6.2としてリリースされていることを確認するために完全なフレームワークが通過した場合は素晴らしいでしょう

@ mgravell + 100。 よく言われる、100％同意した。

実際にどのくらい影響を受けますか？ ここでcoreclrについて話しますか？ .NETデスクトップは、coreclrが追いつくまで、今後何年にもわたって存続します。 不平を言っている人のために、ここであなたは何をカバーしますか？ 多くの人が基本的に世界の終わりだと言っています。

@leppie確かに、それは何年も前から存在するでしょう。 また、これらのハックと回避策をコード内で今後数年間維持する必要があります。 ここでの論点は、2つの間の共通のブリッジの削除です。 そのワークロードは、BCLではなく、すべてのライブラリ開発者にシフトされました。 私はインターフェースの長所と短所の両面を理解していますが、ここのいくつかから「それはマイナーです、先に進む」態度を理解していません。

ここで率直に言ってみましょう。

インターフェイスを削除することのプラス面として、新しいパッケージングモデルが機能する_additional_バージョン管理メカニズムがあります。X、Y、およびZで使用できるクラスは、ツールによってはるかに適切にサポートされるようになりました。 たとえば、現在dotnet5.2と5.4です。 しかし、そこにも欠点があります。 たとえば、SqlClientは、現在のインターフェイスを実装する段階にはまだ達しておらず（dotnet / runtime＃14302およびdotnet / runtime＃15269を参照）、 @ YoungGahが言ったことを

では、5.6（1.5）はどうなるのでしょうか。 より多くのメンバーが抽象クラスに追加された場合、各データプロバイダーは、移動するすべての人によって変化する可能性のある移動するターゲットと歩調を合わせることが期待されますか？ すべての消費者は、それぞれで利用可能な機能のバージョンを決定する必要がありますか？ 渡されるクラスの抽象ベースに一致するように、プラットフォームのバージョンごとにアセンブリのバージョンをコンパイルする必要がありますか？ これらすべてが今後どのように機能するかは、100％明確ではありません。 変更されていないインターフェイスははるかに明確です。 これに加えて、ドキュメントがあります。どの機能、メソッドなどがどのバージョンで利用可能であり、どのバージョンでプラットフォームが利用可能であるかは、今後すべてのライブラリ作成者にとって大きな問題になります。 その懸念はここでは半ば関連しているだけですが、それは関係しています。

今のところ、私は次の2週間で更新を心配して待っています。 私が恐れているのは、メッセージがずっと続いているように、「SQLとEntity Frameworkで機能するので、Xを実行しているので、それで十分です」という言葉を使わずに、効果的になるのではないかということです。 私にとって、図書館の作者側のフラストレーションは、これらの面で（コードとディスカッションの両方で）何ヶ月も進歩が見られなかったことです。

100％同意します。

SqlFu（私のMicro ORM）のv2（およびそれ以降）を設計したとき、拡張メソッドをどこにアタッチするかを決定する必要がありました：DbConnection / DbCommandまたはインターフェイス。 私はこれを見つけて、抽象クラスに行くことにしました。

したがって、 IDataReader削除の影響は受けますが、MSはその知恵で、どのインターフェイスを廃止として扱うべきか、どのインターフェイスを廃止すべきでないかを明確にしないことに決めたため、それほど影響を受けません。 しかし、私の場合、インターフェースを置き換えるのは難しくありません。

ただし、専用のインターフェイスを使用することの価値は理解しており、MSがそれらを保持/追加し直すことはそれほど難しいことではないと思います。 古いインターフェースがそれほどうまく設計されていないと彼らが判断した場合は、問題ありません。 新しいものをより具体的に設計します。 少なくとも将来的には、同じ問題に対処する必要はありません。

（これは米国での感謝祭の週であるため、Microsoftiesによる応答は、来週オフィスに戻るまでかなり制限されます）

繰り返しになりますが、このスレッドで適切な提案やバグが失われないように、現在の基本クラス/表面積、および/または今後のバージョン管理に問題がある場合は、新しい問題を提出してください。この議論はv1インターフェースについてのみ続けましょう。

@NickCraver .NET Frameworkのバージョン間の互換性と同様に、 重大な変更はありません。 たとえば、基本クラスへの抽象メンバーの追加は、行われない変更の例です。

@davkeanあなたはそれが起こらないとどれほど自信がありますか？ 不完全な表面積が見られ、変更される保証がないことを考えると、欠落している部分が後で表示されないとは信じがたいです。 ただし、重大な変更がないことは_もっと_重要なことだと思います。これは、ここのほとんどの図書館の著者も同様に想定していると思います。 つまり、RTMがヒットする前に、これらのアイテムを処理することがさらに重要になります。

記録については、表面領域に個別の問題が提出されています。その後数回更新とアクティビティを要求したにもかかわらず、それぞれ9月25日と10月2日のMicrosoftからの最新の更新を含むdotnet / runtime＃14302とdotnet / runtime＃15269を参照してください。 それは2か月と2つのリリースがあり、沈黙が続いています。 これは、 dotnet / runtime＃14302が

Data Commonチームは、抽象的なメンバーを導入せずに変更を加えることを検討しています。

@NickCraver申し訳ありませんが、ここでは@ YoungGahは、上記の更新を提供しました。進行状況に

@niemyjski

dnxは完全に新しいフレームワーク/ランタイムです

dnxランタイムとcorefxライブラリが薄い空気から現れたと思うなら、それを最初から開発するのにかかる時間を真剣に過小評価しています。 CoreFxライブラリが完全な.NETFrameworkで実行されているという事実から、完全に新しいわけではないという手がかりが得られるはずです。

いくつかのインターフェースがない場合は、コンパイラ指令を使用して処理します。

はい。ただし、コアをターゲットにするときに、コンパイラ指令でそのインターフェイスをポーリングできなかった理由はありません。

このスレッドに飛び込む前にコメントを読むのが面倒だった場合は、a）理由があり、b）これがコアBCLインターフェイスの壊れた実行不可能な戦略であることがわかります。

@nvivo

この説明で考慮すべき重要な事実の1つは、基本クラスが導入された10年前に.NET2.0でIDb *インターフェイスがADO.NETのAPIとして非推奨になったということです。

その場合、10年前に基本クラスによって非推奨になっていることがわかっているインターフェイスの使用に戻るように指示する問題は発生しませんでした。 APIを通信する方法は非推奨です。これは、既存の唯一の目的である[Obsolete]属性を使用することです。 それが広く伝えられていなければ、あなたの考えが今何であるかに関係なく、それは非推奨ではありません。 ほとんどの非MS.NET ORMがそれらに依存しているという事実は、その非推奨が十分に伝達されていなかったことを示しているはずです。

これらのインターフェースに依存するコードがある場合は、非同期メソッドなどをサポートしていない非常に古いAPIに対してコーディングしているため、他のユーザーに引き続き使用してもらいたい場合は、とにかく更新する必要があります。

偽のストローマン-1つは他を意味しません。 非同期APIのサポートはすでに追加されていますが、それらを追加しても、既存のカスタマーコードベースが破損したり、既存のAPIを変更したりする必要はありませんでした。

さて、この全体がクリーンスタートを行うことは素晴らしいことですが、1つの質問をすることができます：あなた自身のフレームワークをサポートするためにどのような妥協がなされましたか？ たとえば、Entity Frameworkを実行するために必要なため、過去のどのような恐怖が移行されましたか？

MicroORMを非表示にするのは残念ですが、.Netコードのパフォーマンスがいくらか向上します（EFは、500ミリ秒で数行をロードできないアプリケーションでは使用できない獣です）。

インターフェイスと基本クラスの場合：再利用できるものがすべて仮想である限り、基本クラスは優れています。 たとえば、WCFで最も苛立たしい設計上の決定の1つは、多くの機能を含む封印されたクラスを大量に使用することです。 XMLメッセージの処理方法を微調整する必要があるとします（相互運用のため）。 1つの小さな関数を継承してオーバーライドする代わりに、再実装する必要があります。 WCFの例では、SOLIDのSがスキップされたため、通常、本番品質であることを確認するために必要なテストを一切行わずに、大規模なインターフェイスを実装する必要があります。

つまり、適応できる基本クラスは良いことです。

Data Commonチームは、抽象的なメンバーを導入せずに変更を加えることを検討しています。

@davkeanそれを保証することは不可能です、そしてあなたはそれを知っています。 ADO.NETは、さまざまな機能を備えたサードパーティソフトウェアと通信するためのサブシステムであり、いくつかの拡張ポイントを備えた共通のAPIを介して公開されます。 データベースランドでも状況は変化し、これらの変化は、これらの外部データベースサービスの通信と利用に使用されるAPIに波及します。 その上：行動の変化もまた重大な変化です。 また、過去数年間、ADO.NETでも（エラー処理など）それらを確認しました。

ADO.NET API全体は、これらの変更の副作用でいっぱいであり、多くの場合SQLServerによって引き起こされます。 一般的に設計されてからSQLクライアントに移行されることはほとんどありませんが、その逆です（たとえば、基本クラスにSqlClientによって無視される機能はほとんどありません）。 それに加えて、サードパーティが必要とするものがAPIに到達することはありませんでした。

つまり、これはAPIであり、最初は.NET 1.0で一般的な設計が行われ（多くの領域で深刻な欠陥があることが判明しました）、それ以降、変更に対応するために左右の機能がパッチされています。風景。 それらの_ほとんど_はまだAPIにあります（すべてではないにしても）。 そして今、マイクロソフトは1つを削除します：インターフェース。

APIのランダムな部分を削除しても、絶対に何も得られません。これによって機能が追加されることはありません（たとえば、ここにプッシュバックする代わりに、それに時間を費やすことができます）が、APIのその部分を利用するコードは機能しません。 このチーズの移動の背後にあるポイントが「最初からやり直す」である場合は、必ず実行してください。ただし、APIを再設計して、真の汎用APIにすることで、長年にわたって積み上げられてきたがらくたを取り除きます。 。

しかし、それは行われていません。 なぜだろうと誰もが不思議に思う必要はありません、私たちは皆その理由を知っています。 また、MS内のチームがインターフェイスの削除によってひどく傷つけられたとしたら、そもそもそれらが削除されることはなかったこともわかっています。

Microsoftが基本クラスを介して新しい機能を追加できるため、サードパーティプロバイダーがその機能の「形式」を自動的に実装できる場合（プロバイダーが実装していない場合にasyncメソッドがsyncメソッドにフォールバックするAsyncのように）、すばらしい：それつまり、サードパーティのORM開発者（そしてそれに直面する：多くの開発者はサードパーティの（マイクロ）ORMのコードを介して_your_ APIにアクセスします）は、1つのクラスをターゲットにするだけです。

しかし、それを行うとは限りません。 たとえば、Microsoft内の誰も、OracleまたはPostgreSqlをADO.NETに追加するための特定の機能に悩まされたことはありません。 たとえば、UDT、ドキュメントツリー、カーソルを介した複数の結果セットの使用など、すべてのADO.NETプロバイダーは、これらの機能を処理する独自の方法を見つける必要があります。 SQL ServerがJSONドキュメントなどのドキュメントツリー機能を取得した場合、ADO.NETはそのための新しいAPIで更新されますか？ 過去にADO.NETプロバイダーからのエラー報告で行ったように？

そのような保証をすることはできません。MSが将来何も壊さないことをここで述べるのは賢明ではありません。 すべてのAPIに欠陥があり、ADO.NETには欠陥がたくさんあります。 いずれにせよ、いつか誰かがそれらを「修正」するでしょう。

つまり、要約すると、APIの他の場所で失敗した部分もADO.NETの一部であるため、インターフェイスはADO.NETの一部です。 これらはAPIを修正するために削除されることはなく、APIがより汎用的なAPIになるようにリファクタリングされることもありません。そのまま残され、DataSet / Tableに依存する要素のように、移植されていないためにいくつかの要素が削除されます（インターフェースが削除されていることを除いて、同様の進展でそれを議論している他の問題です）。

その観点だけでは、それはすでに意味がありません。

@mythz

その場合は、非推奨であることがわかっているインターフェイスの使用に戻るように指示する問題は発生しませんでした。

OPを読んで理解することはできません。 これらの議論は宗教的になりすぎており、あなたは誰も言わなかったことを想定しているだけです。

この問題を開いたのは、インターフェースがAPIの記述に優れており、テストに役立つと信じているためです。 それが行われた場合、問題が発生した15年前のAPIと互換性があるとは思われません。 後方互換性は、皆さんが議論をそれに移すまで、問題のポイントにはなりませんでした。

それだけのために物事が壊れるべきだと私が信じているわけではありません。 しかし、インターフェースのバージョン管理は過去の問題です。 corefxがメジャーバージョン間で何かを変更した場合、予想されるメジャーバージョンには重大な変更があります。 それらがマイナーバージョン間のインターフェースを壊す場合、それはただのだらしなさです。

非同期APIのサポートはすでに追加されています

同期APIの上に非同期APIを追加することはできません。 IDbConnectionまたはIDbCommandを使用してそれを行った場合、それは間違っていました。 これらのインターフェースを使用していない場合、実際には、それらとの下位互換性を擁護する意味はありません。

非同期APIのサポートはすでに追加されています

同期APIの上に非同期APIを追加することはできません。 IDbConnectionまたはIDbCommandを使用してそれを行った場合、それは間違っていました。 これらのインターフェースを使用していない場合、実際には、それらとの下位互換性を擁護する意味はありません。

ADO.NETでは、それが彼らが行ったことです。Asyncメソッドは、デフォルトで同期バリアントにフォールバックします。 このようにして、非同期をサポートしないすべてのADO.NETプロバイダー（読み取り：現時点ではSqlServerを除くすべて）は、サポートしていないものを実装する必要はありません。非同期APIを提供するORMのサードパーティコードは、 ADO.NETの非同期メソッド。ado.netプロバイダーが非同期をサポートしていない場合、実際には誰も知りません。 ええと...遅いのでわかるでしょうが、それはさておき。

これは、ADO.NET内に「設計」または一般的なアーキテクチャがないことの良い例でもあります。一般的なAPIでトランザクションセーブポイントを作成する方法は_ありません_。 ほとんどの_all_データベースは、DbTransactionから派生したクラスの 'Save（string）'メソッドでそれをサポートしていますが。 OleDbTransactionを除くすべて（MS Accessはそれをサポートしていないので、少なくともそれは私の疑いです）。

簡単ではありませんが、誰も簡単だとは言いませんでした。 この問題は新しいものではなく、OleDBとODBCは長年にわたって対処してきました。JDBCはそれを解決する方法を見つけました。マイクロソフトは、このようなことを克服するために車輪の再発明をする必要はありません。 また、DBレルムに固有のものではありません。たとえば、そこにあるすべてのビデオカードは、APIを介して機能のさまざまなサブセットをサポートし、Direct3D / Xを介して開発者に公開されます。 これらの他の世界で設計がどのように行われるかは実際には興味深いものです。APIは設計されており、それをサポートする必要のある関係者（JDBCドライバー、OleDBドライバーライターなど）はこれらを実装する必要があります。 あなたのドライバーはXをサポートしませんか？ お使いのドライバはXに準拠していません。「OracleはADO.NETv10をサポートしていません」。 Oracle内の誰もそれを読みたがりません。 代わりに、SqlClientがリードであり、ワゴンから落ちるものがADO.NETに追加されます。それだけです。

ADO.NETでは、それが彼らが行ったことです。Asyncメソッドは、デフォルトで同期バリアントにフォールバックします。

いいえ、そうではありません。 APIは、デフォルトで同期メソッドにフォールバックする非同期メソッドを公開しますが、プロバイダーは実際の非同期操作でオーバーライドします。 @mythzが述べているのは、彼がIDbCommandとIDbConnectionを使用してそれを行っているということです。

これは不可能です、期間。 あなたがそれをするならば、あなたはそれを正しくしていないか、あなたはインターフェースを使っていません。 基になるAPIが非同期でない場合、非同期を発明することはできません。

いいえ、そうではありません。 APIは、デフォルトで同期メソッドにフォールバックする非同期メソッドを公開しますが、プロバイダーは実際の非同期操作でオーバーライドします。 @mythzが述べているのは、彼がIDbCommandとIDbConnectionを使用してそれを行っているということです。

SqlClientを除いて、公式プロバイダーはこれを行いません。ODP.NETなどの他のすべては、いかなる形式の非同期コードも実装しないため、呼び出しコードは同期バリアント（実際に同期コードを実行するDbDataReader / DbCommandなどの非同期メソッド）にフォールバックします。 ）。 そのため、ユーザーコードは、同期操作を実行する内部にある非同期バリアントを呼び出します。 これにより、実際には非同期が実行されなくなります（すべてのコードは実際には単に同期されるため）。 おそらく、devartのプロバイダーは、独自の実装で非同期APIを実装しています。

とにかく、それはそれを正しく行うことではなく、APIのバージョン管理についてです。

@nvivo

この問題を開いたのは、インターフェースがAPIの記述に優れており、テストに役立つと信じているためです。 それが行われた場合、問題が発生した15年前のAPIと互換性があるとは思われません。 後方互換性は、皆さんが議論をそれに移すまで、問題のポイントにはなりませんでした。

コアADO.NETインターフェイスが10年前に非推奨になり、すべてが基本クラスに移動したことはわかっていましたが、今はそれを放棄してインターフェイスに戻り、偶然にも既存のインターフェイスと同じ名前を使用する必要があると考えていましたが、下位互換性は必要ないので、既存のインターフェースはもう存在しないはずですよね？ 確かに、合法に聞こえます。

プラットフォームを前進させたい場合は、APIを時間の経過とともに進化させ、並列でサポートします。これにより、すべての人が並列APIをサポートし、自分のやり方や顧客を計画できるようになります。 警告なしにそれらをリッピングすると、それらに依存しているエコシステムが不必要に破壊され、すべてのダウンストリームの依存関係に複雑さが押し下げられます。

同期APIの上に非同期APIを追加することはできません。 IDbConnectionまたはIDbCommandを使用してそれを行った場合、それは間違っていました。 これらのインターフェースを使用していない場合、実際には、それらとの下位互換性を擁護する意味はありません。

あなたが明らかに知らないことについてのコメントでこのスレッドを汚染するのを止めてほしいと思います。 Async APIがどのように実装されているかを知りたい場合は、ソースコードを読んでください。そして、盲目的に虚偽を広めるのを止めてください。 サードパーティのライブラリがSystem.Dataインターフェイスを拡張することは不可能です。 実装に依存しないAPIを提供します。これは、すべての主要なRDBMSをサポートするために、すべてのADO.NETプロバイダーが外部向けAPI（つまり、コアSystem.Dataインターフェイス）に実装する最小限の依存関係を公開します。 非同期APIは、IDbConnectionから離れた拡張メソッドであり、舞台裏で、それらをサポートする具体的なADO.NETプロバイダーの非同期APIを活用します。 内部的には、非同期のサポートに関係なく、サポートされている各ADO.NETプロバイダーにはすでに具体的な依存関係があります。 「それらとの下位互換性を擁護する意味が実際にはない」というあなたの提案は、経験が浅く、完全に根拠がありません。

これをマイクロソフト側のフェンス（cc @davkean @YoungGah）に

フォローアップ：
答えが「はい」の場合（RTM後のある時点で変更があります）、どのような中断が見られますか？ 追加、新しい方法？ プロバイダーの基本クラスを継承した場合、人々が使用している競合するメソッドなどを追加するとどうなりますか？

答えが「いいえ」の場合（決して）：インターフェイスを追加し直さないのはなぜですか？

このスレッドは、_今_について議論するのに少し時間がかかっています-これは、このようなものをできるだけ早く修正する必要があるため、ほとんどの場合良いことです。 ここにいるすべての図書館の作者は、リリースが完了した後に何かを手に入れることがどれほど難しいかを知っています。 残念ながら、_将来の_追加と変更についての明確な計画がない場合は、十分な情報に基づいて議論する必要があります。

今後の予定は？

この場合、抽象クラスを介して実装を強制するべきではありません。 IMO

Microsoftは、.NET4.5で問題となるような変更を加えることはありません。 これはWindowsの一部です。 互換性が重要です。

Microsoftは、4.5に影響を与えない.NETCoreで壊れている変更を加えることができます。 ADO.NETのような低レベルで1.0RTMを投稿するとは思えませんが、バーは低くなっています。 これはWindowsの一部ではなく、.NETCoreバージョンを並べて展開できます。

抽象クラスは変更できます-それは壊れていません。 デフォルトの実装で仮想のメソッドを追加するだけです。 これは、ADO.NET非同期メソッドですでに実行されています。 .NET Coreの導入により、互換性を維持するために、共有クラスの変更を.NET4.5リリースと協調して行う必要があると思います。 それが間違っていて、インターフェースにのみ適用される場合、誰かが私を訂正します：grin：

@FransBouma

SqlClientを除いて、公式プロバイダーはこれを行いません。ODP.NETなどの他のすべてのプロバイダーは、いかなる形式の非同期コードも実装しないため、呼び出しコードは同期バリアントにフォールバックします。

その通りですが、それはAPIの問題ではなく、実装者による怠惰や理解の欠如です。 たとえば、MySqlコネクタは、TaskCompletionSourceを作成し、syncメソッドでそれらを完了することによって、すべての非同期メソッドを再実装しました。これはばかげています。 コードベースの半分を削除しても、同じ動作を維持できます。

インターフェースがそれを解決するとは言わないが、非同期のデフォルトの振る舞いがないことは、少なくとも一部のインターフェースにこれを考えさせるだろう。 非常に技術的な人々の90％が非同期操作を理解していないという事実も役に立ちません。

抽象クラスは変更できます-それは壊れていません。 デフォルトの実装で仮想のメソッドを追加するだけです。 これは、ADO.NET非同期メソッドですでに実行されています。

これは壊れています。 この実装が追加されたことを知らずにサブクラス化したすべてのライブラリにとっては破綻しており、人々はこの考えを消費します。 ああ、この実装はpostgresqlでサポートされるようになりましたBAM ERRORwtfが発生しました...

データベース抽象化の強制実装は間違っています。

そのインターフェースか基本クラスかは関係ありません。 重大な変更があります。 しかし、強制的に事前定義された実装は間違っています。

ポリモーフィズムはそのようには機能しません。 知らないうちにメソッドをオーバーライドすることはできません。 参照がDbConnectionであり、QueryAsyncを呼び出すと、そのメソッドまたはオーバーライドされたもののみが呼び出されます。 たまたまサブクラスに存在していたQueryAsyncというメソッドは呼び出されません。

メソッドをオーバーライドすることと、同じ名前でメソッドを非表示にすることを混同しています。

@JamesNK

メソッドが抽象として定義されている場合、基本クラスには実装が存在しません。 これにより、サードパーティはサブクラスに実装を追加する必要があるため、サードパーティの契約が破られます。

メソッドを仮想化してオーバーライドできるようにすると、実装は基本クラスに存在し、サブクラスには意味がありません。 ライブラリの作成者によって実装されていない実装が存在するため、これはまだ壊れています。 確かにあなたのアプリはコンパイルでき、すべてが厄介ですが、誰かがそのメソッドを呼び出しており、サブクラスには無効です。 それは間違っている。 これは、サブクラスに属さない強制実装です。

したがって、サブクラスに属さない実装が存在する可能性のある抽象クラス。 または、サードパーティのデフォルトの実装が存在しないインターフェイス。

@ phillip-haydonだからこそ、抽象メソッドではなく仮想メソッドとして実装されています。

同じ署名（名前/引数）を持つメンバーがすでにあるサブクラスのみを壊すものを追加できます。 引数が異なる場合、開発者がオーバーロードを間​​違えると、微妙なバグが発生する可能性があります。

これは、サブクラスに属さない強制実装です。

それならそこに置かないでください。

@jamesnk

そこに置かないでください。 そのため、インターフェイスの削除について議論しています。

仮想化しても問題は解決しません。 事前定義された実装があってはなりません。 話の終わり

@JamesNKこの場合、私たちはそれをそこに置きませんでした、_Microsoft_はそれを要約に含めることによってそこに置きました。 継承するすべてのプロバイダー間で機能すると想定されるメソッドを追加すると、技術的に壊れていなくても、効率的にスムーズに進むとは思えません（「新しい」コンパイル警告を_技術的に_壊れていないことを認めます）。 ほとんどの場合、共有またはすぐに共有される実装はありません。 では、代替手段は何ですか？ その仮想内のthrow new NotImplementedException() ？ それがそもそも存在することについての議論はほとんどありません、それはより多くの（実行時の）問題でいっぱいです。

今日を見てみましょう：混乱と非効率につながる内部で同期する一連のメソッドではなく、プロバイダーがサポートするときにIDbAsyncConnection追加されることを望んでいます。抄録。

混乱と非効率につながる内部で同期する一連のメソッドではなく、プロバイダーがIDbAsyncConnectionをサポートするときに、IDbAsyncConnectionが追加されることを望んでいます。

@ NickCraver + 、ここでのOracleチームはちょうど手段を非同期かを理解しません。

あなたはインターフェースでそれを行うことができます。 それらの問題は、複数のインターフェースを要求する引数を受け入れることができないことです。たとえば、IDbAsyncConnectionとIDbConnectionの両方であるタイプが必要です。 強い型付けを失い、インターフェイスのCOMスタイルのクエリを開始する必要があります。これはあまりユーザーフレンドリーではないと思います。 それはその場所を持っているAPIデザインのツールですが、私がデフォルトでそれに行くかどうかはわかりません。

デフォルトの実装がNotImplementedExceptionをスローしていた場合、それを基本クラスにボルトで固定するのは間違ったことです。 私が言ったように、それをそこに置かないでください。 誰かがそれをしているのを見たら、問題を提起します。

いずれにせよ、それがインターフェースであろうと抽象基本クラスであろうと、私の経験では、元々それらのために設計されていなかった新しい機能を、世界を壊すことなくライブラリに追加することは非常に困難です。

@JamesNKはおそらくIDbAsyncConnectionがここでIDbConnection IDbAsyncConnectionを継承しますが、必ずしもそうである必要はありません。共通のメンバーを共有したり、共通のベースから継承したりできます。 たとえば、Dapperでは、おそらく次のように実装します。

`` `C＃
IEnumerableクエリ（このIDbConnection cnn、CommandDefinition cmd）

``` C#
Task<IEnumerable<T>> QueryAsync<T>(this IDbAsyncConnection cnn, CommandDefinition cmd)

sync / asyncメソッドを使用するほとんどのライブラリは、同様の使用法と実装を持っていると思います。

_編集：_入力した後、名前の末尾のAsyncがこれらすべてにどれだけ優れているかを理解しました...

ADO.NETには、何年にもわたって次の大きな変更がありました。

1. 2003（1.1）に、彼らは1.0から大幅な変更を加え、再設計しました。
2. 2005（2.0）に、彼らは現在存在する基本クラスを備えたプロバイダーモデルに移行しました。
3. 2012（4.5）に、非同期サポートを追加しました。これは、同じことを非同期で実行する新しいメソッドを追加する以外は実際には何も変更しませんでした。

2003 apiが定義された方法に戻ると、互換性が失われるか（人々は望まない）、過去10年間に追加された機能が削除されます。 ただし、現在の設計で.NET Coreに新しいインターフェイスを追加することは、どの.NETバージョンとも_ソース互換_です。 過去15年間に記述されたほとんどのコードを機能させるために必要なのは、再コンパイルだけです。 そして、とにかくcorefxをターゲットにするために再コンパイルする必要があります。

このAPIは長い間安定しています。 人々が望むなら、それはインターフェースとして再設計されるかもしれません。 いつものように、ここには技術的な問題はありません。それは、傷跡、好み、そして自我に要約されます。

インターフェースを元に戻し、廃止のマークを付けてみませんか？

このアイデアは削除されましたが、アセンブリニュートラルなインターフェイスがこの種の状況で役立つかどうか疑問に思っています。このhttp://davidfowl.com/assembly-neutral-interfaces/を参照してから、それらの実装を参照してください。
http://davidfowl.com/assembly-neutral-interfaces-implementation/

ここでは、アセンブリニュートラルインターフェイスは真っ赤なニシンだと思います。 どちらかといえば
「共通」が存在するので、これは完全に「共通」のことです。 それに加えて
機能が蒸発したため、議論の余地があります。
2015年11月28日午後5時38分、「ShahidKhan」 [email protected]は次のように書いています。

このアイデアは削除されましたが、アセンブリが中立かどうか疑問に思っています
インターフェースは、この種の状況でこれを参照するのに役立つ可能性があります
http://davidfowl.com/assembly-neutral-interfaces/そして彼らの
実装
http://davidfowl.com/assembly-neutral-interfaces-implementation/

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/dotnet/corefx/issues/3480#issuecomment-160323344 。

私が観察すること：

• CoreClr（新しい光沢のあるフレームワーク）のアイデアの背後にいる人々は、その実装の背後にある人々とはまったく異なる考え方を持っています（15年前のコードベースとの下位互換性が重要です）。

私が思うこと：

• インターフェースを削除することで、事態はさらに悪化します。
• [廃止]で飾られるまで、廃止されるものはありません。 そして、いつでも誰が何を考えているかは問題ではありません。 これは契約であり、あなたが単にそれを満たさないのであれば、あなたはそうではありません。

私が欲しいもの：

• 基本クラスではなく、APIの基本サーフェスとしてインターフェースを使用します。

私が感じるもの：

• 私たちは2015年後半になり、人々がこれについて議論しているのを見るのはイライラし、悲しいことです。

インターフェイスはバージョン管理できません。

確かに、インターフェイスはインターフェイスの継承で簡単にバージョン管理できますか？ そして、それがまったく異なることをしている場合。 まあその別のインターフェイス。

interface IOldInterface {}
interface INewInterface : IOldInterface {}
interface IDifferentInterface {}

class SomeClass : IOldInterface, INewInterface, IDifferentInterface
{
}

IInterfaceV2 、 IInterfaceV3とは呼ばないでください。何が追加されるかを説明する必要があります。

古いインターフェース[Obsolete]をコンテキストに入れ、いくつかの新しいインターフェースを使用して、それらを実際のインターフェースと呼びます。 この時代では、非同期ではない方法が正常に見えるのではなく。

public interface IDbUtilityProviderFactory 
{
    IDbConnectionStringBuilder CreateConnectionStringBuilder();
    IDbParameter CreateParameter();
}

public interface IDbBlockingProviderFactory : IDbUtilityProviderFactory 
{
    IDbBlockingCommand CreateBlockingCommand();
    IDbBlockingConnection CreateBlockingConnection();
}

public interface IDbAyncProviderFactory : IDbUtilityProviderFactory 
{
    IDbCommandAsync CreateAsyncCommand();
    IDbConnectionAsync CreateAsyncConnection();
}

@abatishchev

CoreClr（新しい光沢のあるフレームワーク）のアイデアの背後にいる人々は、その実装の背後にある人々とはまったく異なる考え方を持っています（15年前のコードベースとの下位互換性が重要です）。

これを明確にしてくれてありがとう、指摘する必要があるようです。 一般的に、MSチームは、言語とそのプラットフォームの両方を進化させるために不可欠な下位互換性に深く関心を持っていると思います。 System.Dataに関する決定は、より広いエコシステムを考慮して行われていないというだけです。これらのコア抽象化は同等に機能するはずです。

• インターフェースを削除することで、事態はさらに悪化します。
• [廃止]で飾られるまで、廃止されるものはありません。 そして、いつでも誰が何を考えているかは問題ではありません。 これは契約であり、あなたが単にそれを満たさないのであれば、あなたはそうではありません。

正確に。

インターフェイスのバージョン管理について。 私が間違っている場合は訂正してください。しかし、CoreClrのポイントは、よりきめ細かく、独立したバージョン管理だと思いましたか？ 大きな変化？ ブーム！ 新しいメジャーバージョンがリリースされました。
15年間の設計経験の後、同じ過ちを繰り返すことになりますが、今では独立してバージョン管理され、リリースされたnugetパッケージがあります。 上記の議論は、もはやそうではありませんが、古き良きモノリシックフレームワークと同じです。
下位互換性が必須の場合は、これらのインターフェイスを削除することはできません。 そうでない場合は、それについて話すのをやめて、APIを最初から設計しましょう。今回は、主要なORM作成者や他のADO.NETの経験豊富な開発者の話を聞きます。
ありがとうございました。

@abatishchev非常に良い点。 私自身も疑問に思いました。下位互換性の議論のポイントは本当に何ですか？ CoreClrに新しい機能が追加された場合、それを使用するすべてが.net fullで実行されるわけではないため、安全のために、一般的な態度しか使用できません。 （それは決してうまくいきませんでした）。

私の側の長い沈黙のために申し訳ありません。

.NETCoreへの移植

まず、部屋の中の象について話しましょう。つまり、.NET Coreには、私たちを含む多くの人々が期待するほど多くのAPIがありません。

私はチームと協力して、既存のアセットを.NETCoreに移植する領域にどのように取り組むかについての一連のドキュメントをまとめています。

現在.NETFramework / Monoにのみ存在する機能を.NETCoreに移植することを計画しています。 このドキュメントでは、それをどのように行うか、どのように優先順位を付けるか、およびメカニズムはどうなるかについて説明します。 その作業をオープンに行うだけでなく、コミュニティがより多くの機能を移植できるようにしたいと思います。

重大な変更

人々が.NETCoreについて話すときに、多くの混乱を引き起こす領域が1つあります。 1つのことを明確にしましょう：

.NETCoreのAPIが.NETFrameworkよりも少ない場合でも、重大な変更ではありません。

その理由は、.NET Coreは新しいプラットフォームであり、技術的には任意のAPIセットを持つことができるためです。 ただし、もちろん、任意のセットは必要ありません。これは、過去に行ったことです。 .NET Coreの目標は、.NETFrameworkおよび.NETCoreで実行されるライブラリ（およびある程度の範囲のコンソールアプリを使用して）を作成できるストーリーを作成することです。 これには、100％互換性のある両方のプラットフォームのサブセットが存在する必要があります。 その文脈で、あなたは私たちが変化を壊すことについて話すのを聞くでしょう。

その上、私たちの意図は、.NETCore内に高い互換性のあるバーを設けることです。 つまり、.NET CoreAPIのあるバージョンと別のバージョンの間でAPIを壊すような変更を行う予定はありません。

インターフェース

インターフェイスへのメンバーの追加は、定義上、重大な変更です。 影響は少なく、それをモデル化する方法があると主張する人もいますが、今日のところ、それはバイナリであり、ソースを壊すような変更です。

WinRTはCOMに基づいているため、インターフェイスに大きく依存しますが、 IFoo 、 IFoo2 、 IFoo3などのインターフェイスをさらに作成することで、この問題を解決します。 それは実行可能ですが、それを耐えられるようにするためのランタイムまたは言語機能がなければ、確かに厄介です。 これまでのところ、そのような機能は存在しません。 しかし、言語デザインチームの一員として、私は提案を聞くことに非常に興味があります。 他の言語やプラットフォームもその分野で関連するアイデアを持っており、私はオプションも積極的に検討しています（ミックスイン/特性、Swiftの拡張機能-すべて、またはインターフェイスのデフォルトメンバーなど）。

下位互換性を引き続き考慮しているため、通常、インターフェイスよりも抽象ベースタイプを優先します。

ADO.NETインターフェイス

そうは言っても、このスレッドの元の質問、つまりADO.NETプロバイダーインターフェイスの公開について話しましょう。

Davidが説明したように、.NET 2 / Visual Studio 2005にあった抽象ベースタイプが導入されたときに、これらは非推奨と見なされました。これらのインターフェイスを持つことは、ORMフレームワークを.NETCoreに移植するために重要であると強く信じられているようです。 私にとって、これは、インターフェイスを.NETCoreに移植する必要があるという十分な証拠を提供します。

ただし、すべての新しいAPIと同様に、コンポーネント化されたスタックを持つことである.NETCoreの主要な目標の1つに注意する必要があります。 インターフェイスIDataReaderはDataTableに依存しており、 DataSet依存しています。 dotnet / runtime＃14302で概説されているように、 DataTableサポートを追加することに反対していませんが、 DataSetレガシーを考慮しています。 ただし、それでも別のパッケージとして追加する場合がありますが、どちらの方法でも、インターフェイスから依存関係チェーンを切断する必要があります-> DataTable -> DataSet 。 @YoungGahとそこで何ができるかを確認します。

このアプローチは懸念に対処しますか？

私が間違っていない限り、IDataReaderの唯一のDataTable依存関係は
GetSchemaTable（）メソッド、DataTableですでに詳細に説明されています
鎖。 しかし、私はすぐに認めます
後日、同様の機能の_some_マインドを追加したいと考えています（かどうかにかかわらず）
DataTable経由かどうかにかかわらず）これを公開するのは非常に厄介です
後でインターフェイスを拡張するのは問題があるため、インターフェイス。 それはないでしょう
「今のところメソッドを削除し、後で何かを追加する」と同じくらい簡単です
2015年12月5日午前0時17分、「ImmoLandwerth」 [email protected]は次のように書いています。

私の側の長い沈黙のために申し訳ありません。
.NETCoreへの移植

まず、部屋の中の象、つまり.NETについて話しましょう。
Coreには、多くの人々ほど多くのAPIが利用可能ではありません。
私たち-期待します。

私は自分のチームと協力して、私たちがどのように進んでいるかについての一連のドキュメントをまとめています。
既存の資産を.NETCoreに移植する領域にアプローチします。

現在のみの機能をさらに移植する予定です。
.NET Framework / Mono to .NETCoreに存在します。 この文書は呼びかけます
それをどのように行うのか、どのように優先順位を付けるのか、そしてメカニックは何をするのか
なれ。 その仕事を野外でやってもらいたいだけでなく、
コミュニティを有効にして、より多くの機能を移植できるようにします。
重大な変更

人々が話しているときに多くの混乱を引き起こす1つの領域があります
.NETCore。 1つのことを明確にしましょう：

.NET CoreのAPIが.NETより少ない場合でも、重大な変更ではありません。
フレームワーク。

その理由は、.NET Coreは新しいプラットフォームであり、技術的には
APIの任意のセットがあります。 しかし、もちろん、私たちは望んでいません
任意のセット
http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
-それは私たちが過去にしたことです。 .NET Coreの目標は、
人々がライブラリを作成できる（そして特定のコンソールアプリを使用して）ストーリー
.NETFrameworkおよび.NETCoreで実行されるアプリも拡張します。 この
100％である両方のプラットフォームのサブセットが存在する必要があります
互換性。 その文脈で、あなたは私たちが変化を壊すことについて話すのを聞くでしょう。

その上、私たちの意図は、.NETCore内に高い互換性のあるバーを設けることです。
言い換えれば、APIを壊す変更を実行する予定はありません
.NET CoreAPIの1つのバージョンと別のバージョン。
インターフェース

インターフェイスへのメンバーの追加は、定義上、重大な変更です。
影響は少なく、モデル化する方法があると主張する人もいます
それですが、今日のところ、それはバイナリとソースを壊す変更です。

WinRTはCOMに基づいているため、インターフェイスに大きく依存します。
IFoo、IFoo2などのインターフェイスをさらに作成することで、この問題を解決します。
IFoo3。 それは実行可能ですが、ランタイムがないと確かに厄介です
それを耐えられるようにする言語機能。 これまでのところ、そのような機能は存在しません。
しかし、言語デザインチームの一員として、私は非常に興味があります。
提案を聞く。 他の言語やプラットフォームには、それに関連するアイデアがあります
スペース、そして私は積極的にオプションも検討しています（
ミックスイン/特性、Swiftの拡張機能-すべて、またはのデフォルトメンバー
インターフェイス）。

私たちはまだ下位互換性を気にしているので、私たちは一般的に好んでいます
インターフェイスを介した抽象的な基本タイプ。
ADO.NETインターフェイス

そうは言っても、このスレッドの元の質問について話しましょう。
ADO.NETプロバイダーインターフェイスを公開します。

デビッドが説明したように：抽象的なベースが
.NET 2 / Visual Studio2005にあったタイプが導入されました。
これらのインターフェースを持つことが重要であるという強い信念があります
ORMフレームワークを.NETCoreに移植します。 私にとって、これは十分な証拠を提供します
インターフェイスを.NETCoreに移植する必要があります。

ただし、すべての新しいAPIと同様に、次のいずれかに注意する必要があります。
コンポーネント化されたスタックを持つ.NETCoreの主な目標。 NS
インターフェイスIDataReaderは、DataTableに依存しています。
DataSetへの依存。 dotnet / runtime＃14302に概説されているように
https://github.com/dotnet/corefx/issues/1039 、追加することに反対していません
DataTableのサポートですが、DataSetを移植する必要はありません。 そう
インターフェイスを追加するには、その依存関係を解除する必要があります。 一緒に仕事をします
@YoungGah https://github.com/YoungGahを使用して、そこで何ができるかを確認してください。

このアプローチは懸念に対処しますか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/dotnet/corefx/issues/3480#issuecomment-162115855 。

はい、IDataReaderはDataSetに依存しているDataTableに依存しています。

前述のように、インターフェイスからメンバーを削除することはできないため、他の方法でその依存関係を解除する必要があります。 インターフェイスを移植しないか、DataTable-> DataSetの依存関係を解除します。

このアプローチは懸念に対処しますか？

はい、 GetSchemaTable()メソッドがなくてもADO.NETインターフェイスを復元すると、現在直面しているADO.NETインターフェイスの問題への大きな依存関係が解決されます。

GetSchemaTable()も含まれることを意味する場合は、DataTable-> DataSetの依存関係を壊すことを想定していますが、 GetSchemaTable()依存している人には推奨されるアプローチです（これが私の投票になります）。これが影響する開発者にもっと重みを付けたいと思います。

@terrajobstは、要約と考慮事項の共有に感謝します。

@terrajobst要約と説明をありがとう。 私はNpgsqlを維持しているので、ORMではなくADO.NETプロバイダーの観点から書いています。

.NET Coreでは、Microsoftは、ADO.NETの長年のレガシー機能、つまりDataTable / DataSetとインターフェイスを削除したいと考えていたようです。 これにより、より優れた、よりクリーンなAPIが作成されますが、インターフェースとDataTable / DataSetAPIにすでに依存しているユーザーにとってはかなりの作業が発生します。

個人的には、DataTable / DataSetを強制終了することは良いことであり、新しくより優れたメタデータAPIを導入する必要があると思います（DataTable / DataSetを強制終了しなくてもこれは当てはまると思います）。 最小化しない
この破損がORM（およびその他の）消費者にもたらす苦痛ですが、覚えておくべきことの1つは、破損をクリーンアップして導入する機会があれば、.NETCoreがその機会であるということです。

ここでのもう1つの苛立たしい要因は、ADO.NETインターフェイスを維持することは、DataTable / DataSetも維持することを意味することです。 言い換えれば、私は個人的にインターフェースの問題についてあまり強く感じていませんが、インターフェースを維持することはDataTable / DataSetを維持することを意味し、それはより問題があるように思われます。

まだインターフェースに依存しているORMがいくつあるかわからないし、基本クラスに移行するのにどれだけの労力がかかるかもわからないので、選択はあまり多くありません。ここでクリアします。 しかし、私の直感は、この機会を利用して、たとえ一部の人々が苦しんでいることを意味するとしても、物事を片付けることです...

PS何をするにしても、インターフェイスの爆発的なルート、つまりIFoo2、IFoo3を下らないでください。 それは単なる非解決策です。
PPS .NET Coreで新しい非DataTableメタデータAPIを作成し、.NETCoreライブラリを.NETFrameworkで実行することにした場合、これは、新しいAPIを使用して新しい.NETFrameworkをリリースする必要があることを意味します。 .NETCore。

@terrajobst沈黙を破ってくれてありがとう;）。 中心的な問題は、ADO.NETのデザインが存在しないことだと思います。 かなり長い間存在していませんでしたが、APIのさまざまな部分に表示されます。これは、数分以上考えずに機能を埋め込んだ寄せ集めです（そうです）。 私はこれについて@rojiに同意します：.NETコアは物事について何かをする一生に一度のチャンスなので、.NETコアは下位互換性があるべきであるという（私の意見ではばかげた）ルールによって

とはいえ、ADO.NETの状況が改善されない場合（つまり、一般的なAPIが設計された実際の設計が取得され、それがSqlClientに特化され、その逆ではない場合）。 SQL Serverですが、他のデータベースでは一般的なAPIに追加され、ADO.NETプロバイダーの作成者に任されていません）、次善の策は、インターフェイスとサードパーティの開発者#ifdefを含め、可能な限り移植することです。残されるポットホールの周り。

ただし、DataTableの依存関係は問題になる可能性があります。これは、IDataReaderインターフェイスにより、移植されていない形式の.NET完全な_if_データテーブルとの下位互換性を維持することが困難になるためです。 しかし、それはとにかく失われた原因だと思います。 MSは、.NET fullは.NETコアほど多くの/頻繁な更新を受け取らないと何度も言われていました。そのため、.NETコアに何か_new_が追加された場合、それを使用するとライブラリが作成されるため、誰もそれを使用できません。 .NETフルとすぐに互換性がありません。 私はここで何かを見逃している可能性が高いので、その場合は私を訂正してください:)

それだけでも奇妙な状況になります。下位互換性が必要ですが、実際にはこれを達成するのは難しいようで、とにかく赤いニシンです。 IMHOが最初に対処した場合、その結果を使用して、.NET CoreのAPIをどのように処理するかを適切に決定できます。つまり、古い不適切に設計されたくだらないものを.NETから完全にドラッグする代わりにAPIを改善できます。 すべてのAPIが適切に設計されていないというわけではありませんが、ADO.NETでは（以前の投稿で説明したように）、何年もの間適切に処理されていません。 クリーンな休憩を取り、代わりに、より堅牢で（JDBCは引き続き強力であり、ODBCは25年前と同じように機能します）、変更に適応できるシステムを実装することをお勧めします。

これについてもう少し考えてみると、下位互換性の要件に関する@FransBoumaのコメントは非常に理にかなっています。 .NET Coreの約束の1つは、コンポーネント化されたNugetパッケージのおかげで反復が高速化されることです。代わりに.NET Frameworkの更新が年に1回または2回行われ、.NETCoreの更新は必要なときにいつでもリリースできます。 更新が.NETFrameworkとの下位互換性を壊すことは決してない場合、これの値は厳しく制限されているようです...？

下位互換性は、このADO.NET固有の説明をはるかに超える要件であることを理解していますが、疑問に思っています。

@rojiの逆です

あなたが.Net開発者であり、基盤となるフレームワークのAPIが絶えず変化しているためにビルドが毎週壊れ続ける場合は、別のプラットフォームを検討し始めるまでにそう長くはかからないでしょう。

したがって、それは非破壊的な変更によって推進される高速な反復です。

（編集）
たとえば、クラスインターフェイス、動作の変更（！）、または動作の追加に何かを追加する必要があるまで、変更を中断せずに繰り返すことができます。これは、文字通りの意味での重大な変更ではありません（動作の変更はthoです）が、 .net coreを使用すると、コードが.net fullと互換性がなくなります。そのため、その意味で、.netcoreは.netfullとの下位互換性がなくなります。 どのIMHOが.NETコアに到達するかは、常に.NETフルと同じ（クラス）インターフェイスと動作を最後のバイト（IMHOは持続不可能）まで持つか、後でバックポートされる新機能を取得します（これは文字通り何ですか） MSは、.NETがいっぱいになると言ったので、事実上、下位互換性はありません。 もちろん、フェンスのどちら側にいるかによって異なります。次のように言うと、「動作Bが定義された（クラス）インターフェイスXの共通セットがあり、.NET Coreと.NETの両方がこれらを完全に実装し、XとBが勝ちます」 「将来的に変化する」ということは、X＆Bの外に新しいフレームワークがあり、それが新しいものを手に入れ、正確に物事が変化する可能性があり、未来がどこにあるかを意味します。

たとえば、.netコアのX＆Bで使用されるインターフェイス/クラスは、実際には.NETコアの新しいクラス/インターフェイスのラッパーです。 X＆Bを使用するか、.NETフルと共通のAPIを使用せずに、より優れたデザインの新しいものを使用するかは、開発者次第です。

XとBで不足しているものを回避する方法をすでに#ifdefする必要があるため、両方のフレームワークをサポートする場合、IMHOは、遅かれ早かれ動作が変更されたら（おそらく非常に微妙な場合でも）、. NETCoreの新しいインターフェイス/クラスをターゲットにできることが望ましいです。とにかく、特定の状況での別の例外のように）が発生するため、コードを_new_ API（X＆Bではない）を使用して.NETCoreに「移植」する方が適切です。 とにかく移植する必要があります、少なくともそれは私がそれを見る方法です。

@ ryanbnl 、

@rojiは、フレームワークとコアの両方と互換性があり、独自のリズムで実行できる場合は、フレームワークからの新しい外部パッケージ（GACではないなど）を除きます。 しかし、それはORMプロバイダーにとってさらに多くの変更になる可能性があり、 System.Data.IDbConnectionという名前はすでに使用されています...

@benaadamsは有効なコメントです-私はADO.NETなどの非NugetフレームワークAPIのみを念頭に置いていました。 ただし、これらは懸念されるほど十分なAPIスペースをカバーしているようです-.NET Coreは、実行不能になることなく、これらのいずれも進化させることができません（読み取り：インターフェイスメソッドまたは抽象メソッドの追加）

IDbConnectionに関してどういう意味かわかりませんが...

@rojiは、たとえばSystem.Data.Databaseなどのこれらのタイプを提供する新しいパッケージを意味していました。 コアとフルの両方との互換性を維持するために、完全なフレームワークでGACになるタイプを再定義することはできませんでした。そうしないと、衝突します。

ナゲットポイントについて; これがフルとコアの両方でnugetに存在できなかった理由があります。 現在のSystem.Data api post 4.6.1+を非推奨にしますか？

それは今、より大きな痛みを引き起こすでしょう。 しかし、一部の互換性はすでに壊れており、インターフェイスをドロップするか、 DataSetのみをドロップするため、ORMプロバイダーがcoreclrに対していくつかのやり直しを行う必要があります。

nugetにしてGAC'dの枠組みの外に住んでいた全く新しいAPIがで使用するための下位互換性がある可能性がありnetstandard1.2それは今いくつかのより多くの苦痛だろうけど例えば4.5.2+、coreclr、UWP、モノ/ Xamarinなど-が、おそらくそれ以降よりも良い時期です。

新しいAPIがアケマなどで機能していることを考えると、 DataSetが来ない（またはDataTable ）ことを示しているので、これを閉じる必要がありますか？ dotnet / corefx＃5609のコメントとタイプ転送に基づくと、基本クラスは前進しているようです。つまり、 GetSchemaTable()与えられた場合、インターフェイスは役に立たず、他のいくつかは互換性のためにそれらを持ち込むためにそこにありません。 ...言うのは公平ですか？

何を閉鎖する必要がありますか？ DataTable / DataSetの依存関係が原因でGetSchemaTable()取得できない場合でも、インターフェイスを復元し（必要に応じてGetSchemaを使用しない）、依存関係の深い既存のコードベースの移植を容易にする必要があります。 欠落しているインターフェースはブロッカーです。dnx/ coreをサポートする作業を開始する前に、インターフェースのリリースをまだ待っています。

私は@mythzに同意します。インターフェースは別の主題であり、非常に重要です。 ほとんどのユーザーには当てはまらないかもしれませんが、これらの同じユーザーは、小さなグループによって記述されたコードを使用し、そのコードはこれらのインターフェイス（およびDbProviderFactoryなどの他の重要な欠落しているADO.NET機能）に依存しています。

正直なところ、「RTM」ラベルへの極端な推進により、1.0で確実なAPIが得られることはほとんど期待できません。 再び.NET2.0のようになります。最初のバージョンで発生したすべての間違いが修正されます。

@FransBouma

.NET Coreにインターフェイスを追加すると、追加の変更になります。 そのため、V1に対応していなくても、1.1以降のどのバージョンでも追加できます。

その後、最初のバージョンで行われたすべての間違いが修正されます。

不快感はありませんが、それがソフトウェアの仕組みです。

@terrajobst

そのため、V1に対応していなくても、1.1以降のどのバージョンでも追加できます。

ええ、それは技術的に不可能であるというわけではありません、それはそうすることの結果（またはそうすることの欠如）が（広範囲に及ぶ）結果をもたらすということです、それのマイクロソフトは苦しんでいる人ではありません、それは私たちです。 これまでのところ、私はそれに対してほとんど無関心を見てきませんでした。 新しいフレームワークに取り組むことはすべてクールでエキサイティングですが、新しいオーディエンスのためのクリーンルームで開発されたものではありません。 それどころか、学ぶべき歴史がないというわけでもありません。

不快感はありませんが、それがソフトウェアの仕組みです。

ほら、これはまさに私が上で意味していることです：あなたはあなたの決定の結果に対処しなければならない人ではありません、私はしなければなりません。 そして、私はあなたの前任者による同様の決定の結果をすでに扱ったので、あなたが同じ過ちを犯さないように私はあなたに注意を向けました。

私はソフトウェアがどのように機能するかを知っています。私は21年以上プロのソフトウェア開発者です。 私は、初心者としてではなく、この特定の分野での戦いに強い専門家として、正直なアドバイスをしました。 あなたはそれであなたがやりたいことをすることができます、それは結果が広範囲に及ぶので、ここで軽く決定を下す前にあなたがよく考えてくれることを願っています、そして私が言ったように：私たちはあなたではなくこれらに対処しなければなりません。

間違いも後で直せるのですが、まだできていないので、そもそもやらないのは当然ですね。

君たちは過剰反応している。 これの影響が古い.NETと同じ結果になるとは思えません。

各アプリケーションにcoreclrがバンドルされているため、レガシーの意味は大きく異なります。 asp.net mvc5の機能がmvc4または3にバックポートされていなくても、ほとんど誰も気にしません。ここでのレガシーは別の意味を持ち、他のプロジェクトにはそれを示す歴史があります。

@terrajobstは、次のバージョンでこれを検討できるようになっています。

@nvivo _I_が対処しなければならない結果を軽視しようとしないでください。対処する必要はありませんが、私はそうします。

私を私の場所に置いてくれてありがとう@FransBouma 。 この問題についてコメントできると思ったのは私の間違いでした。 あなたは確かに私よりも、私の仕事にどのような影響があるのか​​を知る資格があります。

実際、私はこの号を開いたが、それは私の仕事や私が気にかけていることに全く影響を与えない。 私はちょうどあなたのような貧しい開発者が地球上ですべての大変な仕事をしていることを考えていました。

私はあなたのような人々が難しい問題の世話をするためにここにいることを本当にうれしく思います。 あなたが対処しなければならないもっと重要な問題がどれほど重要であるかを何度も何度も（そして何度も）私たちに話すことを躊躇しないでください。

@FransBoumaありがとうございます。

_ため息_私はそれをどこで言いますか？ 私が言うのは、物事を軽視しないでください。「あなたは過剰反応している」でそうするので、私は過剰反応しているとは思いません。 「あなたはそれらに対処する必要はありません」と私は意味します：_me_の結果。 私はそれらが何であるかを知っているので、私は私がしたように反応します。 どうやらそれは「過剰反応」です。

しかし、何でも。

この問題に対する回答はこことここにあり

公式の答えは次のとおりです。インターフェイスは.NETCore 1.0にはありません。可能性は低いですが、.NETに存在していたものとは異なる形式で将来のリリースで検討される可能性があります。

元の質問が解決されたので、この問題を閉じます。

@nvivoありがとうございますが、プロジェクトの実際の責任者であり、問​​題が解決したと判断したら自分で問題を解決できる人には、公式の回答を残すのが最善です。

@terrajobstインターフェースの更新された公式の応答/タイムラインはありますか？ そして、今後この作業項目を追跡するための最良の方法は何ですか？ 新しい号を開く必要がありますか、それともここで更新を提供し続けますか？

とりあえずこれは開いたままにしておきましょう。 私の見方では、答えは「インターフェースを公開しない」ではありませんでした。 答えは、「それらを公開する方法を見つけましょうが、DataTableの依存関係にとってそれが何を意味するのかを考えましょう」でした。

遅くなってごめんなさい。 チーム内でさまざまなオプションについて話し合った後、空のクラスのDataTableを使用してインターフェイスを戻すことにしました。 これは理想的なソリューションではありませんが、RTMの時間枠を考えると、このアプローチにより、将来的にDataTable / DataSetに関する実行可能なオプションを追求できるようになります。 System.Data.Commonのインターフェイスをv1RTMで導入しようとします。 SqlClientは、v1によるインターフェイスを実装しません。 フィードバックと忍耐をありがとう。 あなたのフィードバックは、データスタックを実行可能な製品にするための重要な部分です。

更新のための@ YoungGahthx 、DataTableクラスが空のプレースホルダーになる場合、SqlClient v1によって実装されるのに非常に多くの時間/労力（つまり、それらを抑える）が必要なのは何ですか？

@mythzコストは、基本タイプでインターフェースを実装するか、既存のメソッドにインターフェースを転送することにあります。 コストは最小限である必要がありますが、通常は次のように表示されます：smile：

System.Data.Commonの.NetCoreFXに次のインターフェイスを追加しました

IDataParameter
IDataParameterCollection
IDataReader
IDataRecord
IDbCommand
IDbConnection
IDbDataParameter
IDbTransaction

これはPRhttps ：//github.com/dotnet/corefx/pull/6359で行われました

@ saurabh500素晴らしいもの、thx！

：+1：

：+1：

素晴らしい; これがnugetをヒットするためのマイルストーンはありますか？ rc3？

2時54分に2016年2月25日には、Saurabhシン[email protected]
書きました：

System.Data.Commonの.NetCoreFXに次のインターフェイスを追加しました

IDataParameter
IDataParameterCollection
IDataReader
IDataRecord
IDbCommand
IDbConnection
IDbDataParameter
IDbTransaction

これは、PR dotnet / corefx＃6359https ： //github.com/dotnet/corefx/pull/6359で行われました

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/dotnet/corefx/issues/3480#issuecomment-188577701 。

よろしく、

マーク

PRについてコメントしたように、これらのインターフェイスに非同期メソッドがない理由を理解する必要があります。 提案されたように、これは基本的にADO.NET 1.1インターフェイスの縮小版であり、古いコードとの互換性だけを考えるべきではないと思います。

非同期メソッドが今日のデータベースにアクセスするためのデフォルトの方法であるため、インターフェイスはado.netの現在の状態に焦点を合わせる必要があります。 非同期メソッドの実際のサポートがなければ、これらのインターフェースは最新の開発には役に立ちません
発達。

また、.NET 4.5の非同期メソッドを含めても、DbTrabsaction.CommitAsyncなどのいくつかの追加メソッドも追加する必要があります。

postgresプロバイダーは、非常に便利で必要なCommitAsyncのようないくつかの追加メソッドをAPIに追加しました。

現在のインターフェースはそのままで問題ありません。 それらを変更することの意味は大きすぎます。

非同期モデルは同期モデルとはかなり異なります。ご存知かもしれませんが、非同期モデルを選択する場合は、最後まで実行する必要があります。 したがって、両方のAPIに同じインターフェースを使用する理由は実際にはありません。 非同期API用に新しいものを作成します。

.NETチームがより最新のAPIを提供したい場合は、ADO.NETと呼ばれない新しいAPIを作成してみませんか？ 妨げられる遺産やコミュニティからの苦情はありません。 これは、dnxがどのように配布されるかにもよく適合しますか？ つまり、独立したパッケージ。

：+1：インターフェース上で、良い妥協点。

古いコードとの互換性だけを考えるべきではないと思います。

それがここでの_全体_のアイデアです。 それ以外の場合は、基本クラスで問題ありません。 それは私たちが避けたい移植の苦痛の多くです。

非同期メソッドの実際のサポートがなければ、これらのインターフェースは最新の開発には役に立ちません。

私はこれに同意しませんが、インターフェースの非同期バージョン（今日は誰も実装していません）に必ずしも同意しません。 これは新機能です。 既存のインターフェースにメンバーをさかのぼって追加することはできません。それは、あまりにも多くのことを壊してしまいます。 IDbReaderAsyncか何かを持っていることはクレイジーなIMOではありませんが、それは別の議論です。

デフォルトの実装が同期ラッパーである場合、 asyncメソッドは基本クラスにあるべきではないと強く信じています-それは積極的に悪くて無駄です。 別の提案がある場合はそうですが、繰り返しになりますが、それはとにかく別の問題になるはずです。

わかりました、多分私はここで間違った方法で自分自身を表現したか、私の言葉で強すぎました。

必要に応じて、非同期用の追加のインターフェイスを使用します。 私が気に入らないのは、ADO.NETの公式コントラクト（インターフェイスとは何か）を定義

しかし、非同期メソッドの代替インターフェースがあると、おそらく他の問題が発生します...

デフォルトの実装が同期ラッパーである場合、非同期メソッドは基本クラスにあるべきではないと強く信じています-それは積極的に悪くて無駄です。

私は同意します。これが、ほとんどのプロバイダーが実際の非同期APIをわざわざ実装しない主な理由です。 ただし、2.0以降、基本クラスはプロバイダーの実際のAPIであるため、これを変更すると、インターフェイスを削除するよりもはるかに多くのコードが破損し、おそらくはるかに多くのノイズが発生します。

1.1インターフェースを使用しないようにライブラリをアップグレードすると、過去数年間に作成されたすべての非同期コードを削除する場合と比較して、ほとんど影響がなく、悲惨な結果になります。 妥協点は両方を持っていることです。 今日書かれたコードは非同期APIを使用する必要があるため、それを省略しても意味がありません。

今日書かれたコードはすべて非同期APIを使用する必要があります。

あまりひどく傷つけたくないのですが、その理想の世界は現実とはかけ離れています。 非同期は非常に蔓延し、感染性があります。 ライブラリ内の非同期APIだけに依存することはできず、アプリケーション全体が気まぐれで非同期コンシューマーになることを期待することはできません（コードの_ton_も非同期に変更します）。 同期->どこでも非同期は、多くのデッドロックと効率の理由からも非常に悪いです。 今後何年にもわたって書かれた同期コードがあります。

両方のAPIが強く求められ

1.1インターフェースを使用しないようにライブラリをアップグレードすると、過去数年間に作成されたすべての非同期コードを削除する場合と比較して、ほとんど影響がありません。

何を指しているのですか？ そのようなコードが存在するための非同期APIはありませんでした。 このようなAPIに依存している場合、それらは基本クラスやインターフェースではなく、プロバイダーに直接依存しています。 これによる影響はありません。

今日書かれたコードは非同期APIを使用する必要があるため、それを省略しても意味がありません。

多くのことを省くことは意味がありません...私たち全員がリソース（特に時間）によって制約されているという事実を除いて。 誰かが_永久に_何かを忘れているとは思わない。 テーブルから外れるものはありません。 それはまだ得られていないだけです。 将来の世代のために非同期インターフェースの仕様を開始するために、特に別の問題を開きます。

何を指しているのですか？ そのようなコードが存在するための非同期APIはありませんでした。 このようなAPIに依存している場合、それらは基本クラスやインターフェースではなく、プロバイダーに直接依存しています。 これによる影響はありません。

.NET 4.5では、プロバイダーの基本クラスに非同期メソッドが導入されました。 これは、ほぼ4年前の2012年であったため、しばらくの間ADO.NETプロバイダーAPIの一部でした。 Entity Framework 6（2013年にリリース）は、すべてのプロバイダーでこの非同期APIに依存しています。

非同期メソッドはすでにADO.NETの一部であるため、.NET Coreに含まれていなかった場合、多くの人が悲鳴を上げるでしょう。 ADO.NETで非同期メソッドを使用する_レガシーコード_があります。

これらはADO.NETの_すでに_一部であるため、これは新しいインターフェイスAPIにも存在する必要があることを提唱しています。

人々が非同期APIを使用したい（そしてそうすべきである）場合、彼らはすでに行うことができます
基本タイプを使用して、_この変更の前に_。 最終的に、リクエスト
インターフェイスをサポートするために、下位互換性の理由で作成されました。
インターフェイスにメソッドを追加すると、_これが水から完全に吹き飛ばされます_。
とは言うものの、実際には_extensionmethods_とほぼ同じように可能です。
抽象ベースタイプに対するタイプチェックですが...かなり醜く、そうではありません
痛みIMOの価値があります。

そう; 短いバージョン：私は個人的に非同期を追加することを後回しにすることはできません
インターフェース、それは私たちが最初にそれらを望んでいた1つのことを破壊するので
場所。 非同期が必要な場合：基本クラスに対してコーディングするか、を使用する必要があります
あなたのためにこれらの詳細をグロスするツール。

それらはすでにADO.NETの一部であるため、これは新しいインターフェイスAPIにも存在する必要があることを提唱しています。

これらのADO.NETインターフェイスの目的は、既存のコードとの互換性を維持することであると完全に誤解しています。 これらは_新しい_インターフェースではなく、_既存の_インターフェースです。 新しいAPIにアクセスする場合は、具体的な基本タイプを参照してください。

@nvivo申し訳ありませんが、私はあなたをフォローしていません-私は_interface_APIについて話していました-それらは存在したことがありません。 基本タイプにはすでに同じ*Asyncメソッドがすべて含まれています-欠けている特定のものはありますか？ それらはインターフェースにバンドルされるべきだとあなたは主張していると思います...確かにそうですが、それは私があなたに開くことを勧めるもう一つの問題です。

現在のアプローチを機能させるために必要な基本実装（非同期オーバー同期）は、アプローチ全体を機能させるためのひどいトレードオフであるため、最初からインターフェースであったほうがいいと思います。 ただし、両方の方法を使用することもできません。インターフェイスに移動するか、（現在の場合のように）存在して、中断を最小限に抑えます。

ええ、私たちはここで輪になって行くと思います。 これについては前に述べましたが、コードの移植を支援するためにインターフェースを追加する必要はないと思います。 互換性の観点から、基本クラスは2005年からADO.NETの公式APIであり、プロバイダーが実装しているものです。 IDbCommandまたはIDbConnectionを使用するものはすべて、検索/置換で基本クラスを使用するために簡単に移植でき（移植されるべきでした）、欠点はありません。

あなたがifdefのファンではないことは知っていますが、新しいプラットフォームでこれをサポートすることは、とにかく移行の一部にすぎません。

私はこれがずっとインターフェースであるべきだったことに同意します、しかしそれらはそうではなかったので、私はこの問題が繰り返されないことを望みます。 インターフェイスが追加される場合、それらは少なくとも現在のAPIを表す必要があり、10年前のものではありません。 非同期メソッドは現在のAPIの不可欠な部分であり、それはMicrosoftがかなり長い間進んでいる方向です。 それでもソース互換であり、より完全です。

@mgravell

非同期APIを使用したい（そして使用すべきである）場合は、基本タイプを使用することで、_この変更の前に_すでにそれを行うことができます。

これは何もできないということではありません。 それは建築についてです。 インターフェイスはコントラクトです。.NETCoreは、このコントラクトを再設計されたバージョンのAPIに追加する新しいフレームワークです。

.NET Coreは、本当に古いコードの移行を支援するためだけに、新しいAPIに正式な契約を追加するべきではありませんが、他のほとんどのものはとにかく欠落しています。 それが懸念事項である場合、人々はとにかくコードを変更する必要があるという理由で十分に探していません。

それがチームがしているすべてであるならば、それは大丈夫です..それはただ悪い選択IMOです。

IDbCommandまたはIDbConnectionを使用するものはすべて、検索/置換で基本クラスを使用するために簡単に移植でき（移植されるべきでした）、欠点はありません。

NS。 この問題は、このスレッドで何度も議論されており、これによって影響を受けた直接の経験を持つ複数のライブラリ作成者からのものです。

私はあなたがifdefsのファンではないことを知っています

エンドカスタマーにifdefの使用を要求するソリューションは、開発経験が壊れており、初心者ではありません。つまり、代替手段が存在する場合、顧客がコードに#defを散らかすことを要求する製品は決して成功しません。

インターフェイスを追加する場合は、少なくとも現在のAPIを表す必要があります

これらは新しいインターフェイスではなく、復元されたインターフェイスです。 現在および将来のAPIは基本クラスであり、これらのインターフェースではありません。 ここでは問題はないはずです。これらのインターフェースが存在することを忘れて、これらのインターフェースが復元される前と同じように基本タイプを使い続けることができます。

このスレッドに追加される新しい値はもうありません。 既存のADO.NETインターフェイスが復元されたため、このスレッドを停止できます。 このスレッドで必要なのは、既存のインターフェイスに関連するDataTableとGetSchemaTable()更新だけです。 アーキテクチャの変更を提案したり、新しいインターフェイスを提唱したりする場合は、新しい問題を開いてください。これにより、このリストのすべての人がスパムされるのを防ぐことができます。

@mythz同意しないことに同意しましょう。

私の2セントを別のORM開発者として追加するだけで、抽象クラスは、インターフェイスに支えられていない場合、常にコードの臭いになります。 最小要件のインターフェースAPIでオーバーロードされた抽象クラスとメソッドシグネチャに一致するように提供される新しいインターフェースを見たいと思います。

発言してくれたコミュニティに感謝します。

抽象クラスは、インターフェースに支えられていない場合、常にコードの臭いです

@psib​​erneticその声明を理解するのを手伝ってくれませんか。 これはコードの臭いはどうですか？

@psib​​ernetic

インターフェースと抽象クラスは私たちにコントラクトを与え、どちらも私たちにAPIの抽象化と適切な定義を与えます。 インターフェイスは、複数のインターフェイスを実装できるクラス、または別の基本クラスのサブクラスであるクラスを実装する場合に最も役立ちます（これがその基本クラスの非常に大きな利点であると想定しています）。 特にこの場合、特定のプロバイダーのConnection、Commandなどの具象クラスは、抽象API定義と強いISA関係にあります。 一部の開発者がIDbConnectionまたはIConnectionの具体的な実装をサブクラスに追加する必要があるシナリオを本当に想像することはできません。 ほとんど唯一のシナリオは、抽象クラスからのみ派生する新しいクラスであり、インターフェイスで同じ定義を「複製」することは、API設計者にとってより多くの作業（不要）です。

2つの等しい抽象化を持つ具体的で具体的な利点またはシナリオがありますか？ インターフェースがこの特定のAPI設計の抽象クラスよりも実用的で実際の利点を提供するのはいつですか？

インターフェイスについて私が考えることができる唯一の利点は、それらのインターフェイスに依存する実際の実行コードを減らすために、古いものとの下位互換性が必要なことです。 古いインターフェースがなければ、抽象クラスで十分だと確信しています。

@eocampo抽象クラスは、おそらく「十分に優れた」抽象化とコントラクトを提供することは

@davkeanコードの臭いは、すべてではありませんが、ほとんどの場合、関連性がない可能性のある機能の基本セット全体を実装または継承するように実装者に要求していることです。 代わりに、キャッシュまたはメモリから読み取るIDataReader実装を見たのを覚えています。 DbDataReader抽象クラスがそれを許可するかどうかはわかりませんが、名前は許可しないことを意味します。

ドットネットで主に採用されているベストプラクティスモデルは、インターフェイスを公開し、基本クラスから継承することでしたね。

ドットネットで主に採用されているベストプラクティスモデルは、インターフェイスを公開し、基本クラスから継承することでしたね。

@psib​​erneticいつもとは限りません。 たとえば、MSDNサイトでのこの推奨事項には10年以上あります。 そして、そのガイドラインは、少なくとも.Net Framework2.0からは非常に一般的です。

また、これは、初期の.Netでのライブラリ設計のガイドラインの良いリファレンスです。

http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613

とにかく、ここでの難しい議論は今、2つの主題についてだと思います。

a）インターフェースは下位互換性のためだけのものですか、それとも「ゼロから始める」（コードを壊す）ことで、よりクリーンなインターフェースとAPI設計を可能にすることができます。
b）完全な.Netフレームワークとの互換性がないという犠牲を払って、モダンでクリーンなデザインにどれだけの費用をかけることができますか。 （特にデータアクセスに関する.Net CoreとFullコア間の互換性[最も低レベルで必須の互換性ではありません]）

私の見解では、基本コントラクトとして抽象基本クラスがある場合、互換性のために_interfaces_は古いものと一致する必要があります。 @nvivoは、.Net 2.0以降、公式の契約は抽象基本クラスであるとすでに述べていることを理解しています。そのため、インターフェイスでは互換性の問題は解決されないと考えることができますが、 @ mythzと@mikeobrienもプロバイダーの依存関係に関するハードデータをここに提供していました。 1.1インターフェース上。

スパムをやめ、ここでトピックについて話し合うのをやめるには、この長い会話をもう一度読む必要があります。私たちが取り組んでいる特定のトピックのリストに同意できるかどうか、または2つまたは3つの新しいトピックを作成するのが良いかどうかはわかりません。特定のトピックごとの問題。 ここには良い点がたくさんあるので、私は最初の提案です。 これらすべてを再要約し、ノイズをクリアする方法がわかりません（私の場合でも）。

インターフェイスと言えば、System.Dataの一部を最終的に汎用化する計画はありますか？ System.Dataが.NET1.1を超えてAPIを実際に更新することは決してなく、IEnumerableを取得するために.AsEnumerable（）拡張メソッドなどのハックを使用する必要があることにいつも悩まされてきました。DataTableから。 2.0がリリースされたときにフレームワークの他のすべてが行ったのに、DataRowCollectionのようなコレクションがジェネリックインターフェイスを実装するようにアップグレードされなかったのはなぜですか？

タイプリダイレクトを含むスタブSystem.Dataはありますか？ ODP.NETを使用する必要がありますが、現在は使用できません。

dotnet / corefx＃7874を作成しました

@mgravell @ploeh 「Rickasaurus」の暗黙の型クラスが間近に迫っていました（少なくともF＃の場合、C＃または.NET全般についてはわかりませんhttps://news.ycombinator.com/threads?id=Rickasaurus）。 それらがすべての.NETに適用される場合、問題は解決しますか？

私はHaskellの専門家ではないんだけど、私の理解では、彼らが簡単な上ボルトにあなたをできるようにしたいですIDbConnection 、 IDbConnectionAsync 、およびソースを壊すことなく、事後将来の共有インターフェイスまたはバイナリ互換性、およびサードパーティプロバイダーにすべてを実装することを強制することなく。 これは、簡単なモック性を維持しながら。

これは正しい理解ですか？ もしそうなら、この機能が実際に.NETに登場する可能性はありますか？