인터페이스의 버전을 지정할 수 없기 때문에 추상 기본 클래스로 전환했을 것입니다.

가상이 아닌 메서드가 가상의 다른 메서드를 호출한다고 추측하고 있습니다. 가상 메서드는 성능을 저하시키므로 불필요하게 가상으로 만들고 싶지 않습니다.

@JamesNK 알겠습니다 . 그러나 .NET Core가 새로운 API이고 ADO.NET API가 거의 10년에 걸쳐 매우 안정적이기 때문에 이것이 여전히 유효한 문제라고 생각하십니까? 또한 데이터베이스 액세스에 대해 이야기할 때 가상 메서드의 비용은 데이터베이스 액세스 비용에 비해 왜소하다고 생각합니다.

@NickCraver , @roji , @FransBouma 여러분이 ADO.NET API에 관심이 있는 것 같으니 이에 대해 할 말이 있습니까?

@YoungGah , 이건 추구할 가치가 있는 일인가요?

가상이 아닌 메서드가 가상의 다른 메서드를 호출한다고 추측하고 있습니다. 가상 메서드는 성능을 저하시키므로 불필요하게 가상으로 만들고 싶지 않습니다.

원격 데이터베이스에서 쿼리를 실행하고 결과를 처리하는 과정에서 virtcall에서 손실되는 나노초는 무시할 수 있습니다. 게다가 ADO.NET은 처음부터 이 시스템을 사용했으며(.NET의 다른 많은 API도 마찬가지) 가상 메서드 호출로 인해 DB 코드가 너무 느리다고 불평하는 사람은 아무도 없었습니다.

목록에서 비동기 메서드를 볼 수 있으므로 몇 년 전만 해도 MS는 IDbCommand에 비동기를 추가할 수 없었습니다. 새로운 방법이나 속성이 필요한 내일이 무엇인지 누가 알겠습니까?

인터페이스는 버전을 지정하지 않습니다.

성능은 무언가를 가상으로 만들지 않는 한 가지 이유일 뿐입니다. 임플란트를 위한 표면적을 줄이는 것이 가능할까요? 나는 MS의 누군가가 왜 그렇게 하지 않기로 결정했는지 말하게 할 것입니다. 저는 ADO.NET에 대해 많이 알지 못하기 때문에 추측만 할 뿐입니다.

@JamesNK 귀하의 우려가 타당하다고 생각하지만 고려해야 할 두 가지 중요한 사항이 있습니다.

1. ADO.NET은 10년이 지난 .NET 2.0 이후로 상당히 안정적이었습니다. 비동기 API가 나중에 추가되었지만 API의 동작은 변경하지 않고 비동기 대응 항목만 추가했습니다. 곧 데이터베이스 드라이버 패러다임
2. CoreFx에는 다른 버전 관리 아이디어가 있어야 합니다. 이전 앱에 대해 이전 CLR을 유지할 수 있기 때문입니다. 따라서 인터페이스 버전 관리 문제는 여기에 영향을 미치지 않아야 합니다.

"localhost"에 있는 SQL 서버라도 연결하고 빈 쿼리를 반환하는 데 최소한 몇 ms를 소비한다는 점을 고려하십시오. 실제로 관계형 데이터베이스에 대한 대부분의 _fast_ 쿼리는 ~20ms가 걸립니다.

NSubstitute 또는 Moq와 같은 표준 도구를 사용하여 API를 조롱할 수 있다는 것은 가상 메서드 조회에서 마이크로초를 절약하는 것보다 오늘날 개발자에게 훨씬 더 가치가 있습니다.

나는 여기에 매우 강한 의견을 가지고 있지 않다고 생각하지만 여기에 몇 가지 의견이 있습니다.

• 데이터베이스 액세스를 위한 API에서 가상 대 비가상을 제거하는 것은 무시할 수 있다는 점에 동의합니다.
• 기본 클래스는 ADO.NET이 구현을 제공할 수 있도록 합니다. 이것이 대부분의 비가상 비가상 메서드에 관한 것입니다. CommandBehavior를 허용하지 않는 ExecuteReader의 오버로드는 CommandBehavior.Default 를 오버로드에 전달합니다. 그렇군요. 인터페이스로 전환하면 모든 공급자는 정확히 동일한 상용구로 ExecuteReader()를 구현해야 합니다...
• 이것이 모든 주요 모의 프레임워크에서 유효한지 확실하지 않지만 적어도 Moq에서는 인터페이스만큼이나 기본 클래스를 모의하는 것이 쉽지 않습니까?

따라서 기본 클래스나 인터페이스 중 하나를 삭제한다는 아이디어는 전반적으로 좋아 보입니다(더 간단합니다). 인터페이스에 대한 이점이 없다고 생각하고(조롱의 용이성에 대해 내가 틀리지 않는 한) 기본 클래스는 공통 기능(즉, 가상이 아닌 비추상 메서드)을 제공할 수 있기 때문에 인터페이스를 덤프하는 Microsoft의 접근 방식을 추측합니다. 나에게 좋은 것 같습니다 ...

나는 그의 모든 요점 에 대해

@roji 는 기본 클래스를 삭제하는 것이 아니라 인터페이스를 기본 API로 추가하는 것을 제안합니다. 기본 클래스는 여전히 기본 동작을 구현할 수 있습니다.

테스트에 관해서는 내 API가 올바른 메서드를 호출하는지 테스트하는 데 큰 문제가 있었습니다. 예를 들어 ExecuteDataReader가 올바른 매개변수를 수신했는지 확인하려면 내부적으로 다른 매개변수를 사용하여 호출되는 다른 보호된 메서드를 확인해야 합니다. 이것은 이상적이지 않습니다.

현재 내가 실수하지 않는 한 ADO.NET API를 조롱할 수 있는 유일한 프레임워크는 호출을 가로채서 모든 것을 조롱할 수 있는 MS Fakes 프레임워크입니다. Moq와 다른 사람들은 그렇게 할 수 없습니다.

다른 사람들도 비슷한 문제가 있는지 알고 싶습니다.

@roji 는 기본 클래스를 삭제하는 것이 아니라 인터페이스를 기본 API로 추가하는 것을 제안합니다. 기본 클래스는 여전히 기본 동작을 구현할 수 있습니다.

죄송합니다. 제가 잘못 이해했습니다. 이 경우, 당신의 제안은 .NET에서 있는 그대로를 유지하고 있지 않습니까(문제가 없다는 것은 아닙니다)?

테스트에 관해서는 내 API가 올바른 메서드를 호출하는지 테스트하는 데 큰 문제가 있었습니다. 예를 들어 ExecuteDataReader가 올바른 매개변수를 수신했는지 확인하려면 내부적으로 다른 매개변수를 사용하여 호출되는 다른 보호된 메서드를 확인해야 합니다. 이것은 이상적이지 않습니다.

귀하의 시나리오를 이해한다면(확실하지 않음) Moq의 CallBase 는 이런 종류의 시나리오에 유용합니다. 기본 구현은 기본 클래스에서 상속됩니다.

@roji

당신의 제안은 .NET에 있는 그대로를 유지하고 있지 않습니까(문제가 없다는 것은 아닙니다)?

정확히. 인터페이스 API는 .NET 1.0에 추가되었으며 2.0에서 더 이상 사용되지 않습니다. 2.0부터 인터페이스는 호환성을 위해 존재하지만 Data.Common에는 ProviderFactory 또는 다른 클래스에 대한 인터페이스가 없습니다. 비동기 API 또는 2.0 또는 최신 메서드에 대한 것도 없습니다.

Moq는 조롱할 수 있는 것만 조롱할 수 있습니다. 재정의할 수 있는 가상 또는 추상 메서드 또는 호출할 수 있는 보호된 메서드가 있어야 합니다. 현재 API는 경우에 따라 메서드를 제공하지만 대부분은 그렇지 않습니다. 리플렉션을 사용하지 않는 한 내부적이고 사적이며 손이 닿지 않는 많은 것들이 있습니다. 참조를 shim으로 대체하기 때문에 MS Fakes만 이를 수행할 수 있지만 이는 VS Enterprise에서만 사용할 수 있으며 오픈 소스 프로젝트에는 쓸모가 없습니다.

매우 구체적인 사례가 있는 것 같지만 확실히 이 API를 조롱하려고 시도한 사람이라면 누구나 이 문제에 직면했습니다. 그냥 구글, 거의 모든 솔루션은 "레거시 인터페이스 API를 조롱하거나 조롱할 수 있는 래퍼를 빌드"로 끝납니다.

@nvivo 네 , 추가 세부 정보에 감사드립니다. 저는 ADO.NET을 조롱하는 데 그리 멀리 가지 않았다는 것을 인정합니다.

내가 이해하지 못하는 것은 API의 내부, 비공개 및 기타 방법이 닿지 않는 방법을 조롱하려는 이유입니다. 자신의 애플리케이션 코드(테스트하려는 코드)에 직접 사용할 수 있는 공개 메서드를 조롱해야 하지 않습니까? 가상이 아닌 메서드(예: 0 매개 변수 ExecuteReader() 오버로드)에 문제가 있지만 ADO.NET에서 이러한 메서드가 항상(?) 가상 오버로드(예: ExecuteReader(CommandBehavior))를 호출한다는 점을 감안할 때 여기서 진짜 문제?

문제 시나리오를 이해하려고 할 때 간단한 예를 들어 주시겠습니까?

@nvivo 이 스레드의 여러 사람들이 이미 지적한 버전 문제로 인해 현재 인터페이스를 가져올 계획이 없습니다. 뒤쳐지는 인터페이스의 좋은 예는 .NET Framework 4.5에 비동기 및 스트리밍 메서드가 추가된 경우입니다. 이러한 새로운 기능을 추가할 때 인터페이스 확장을 주의 깊게 살펴보았습니다. 당시 우리가 가진 옵션은 InterfaceFooV2를 제공하거나 asyn 및 스트리밍을 위한 별도의 인터페이스를 제공하는 것이었습니다. 앞으로 더 많은 API를 추가할 수 있기 때문에 InterfaceFooV2를 추가하고 싶지 않았습니다. 각각의 새로운 기능에 대해 별도의 인터페이스를 계속 추가하면 기존 인터페이스에 연결되지 않기 때문에 혼란스러울 수 있습니다.

@roji "오버로드"가 아닌 ExecuteReader의 특정 오버로드가 호출되었는지 확인하려는 경우가 있었습니다. 그것은 사용자 코드가 아닌 라이브러리에만 있는 종류입니다.

@YoungGah 정보 감사합니다. 그럼 닫겠습니다.

이 변경에 책임이 있는 사람들이 그 효과에 대해 알고 있습니까? 핵심 ADO.NET 인터페이스는 10년 이상 사용되어 왔으며 데이터 액세스가 대부분의 비즈니스 앱의 중심이었습니다. 의도적으로 그렇게 많은 기존 코드 기반을 깨뜨리지 않는 것이 최우선 순위가 아니라는 점을 이해하는 데 문제가 있습니다. 이들은 .NET에서 가장 중요한 고급 인터페이스 중 일부이며, 이러한 중단을 제거하면 모든 ADO .NET 데이터 액세스 라이브러리가 중단되고 결과적으로 이를 사용하는 모든 프로젝트가 중단됩니다. 이를 제거하면 인위적인 조각화가 생성되어 CoreCLR 채택을 방해하는 좌절과 혼란을 야기합니다.

새로운 API의 IDbCommand 대한 확장 메서드를 추가하기만 하면 인터페이스 버전을 유지하고 소스 호환 가능하게 만들 수 있습니다. 예:

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 개발자 시장에 대해 많은 홍보를 하고 있기 때문에 alt RDBM에 대한 지원이 많을수록 좋습니다. Micro ORM을 채택한 개발자 집단의 또 다른 중요한 특성은 자신에게 가장 적합한 ORM을 선택하기 위해 MS 생태계 기본값 외부에서 평가했다는 것입니다. 내가 본 모든 것에서 활성 .NET OSS(즉, 암흑 물질 방지) 개발자와 Micro ORM을 채택한 개발자 사이에는 높은 상관 관계가 있으며 마찬가지로 CoreCLR의 얼리 어답터와 높은 상관 관계가 있을 것으로 예상합니다. 주요 가치 제안은 다음과 같습니다. OSX/Linux에서 개발합니다. 이것이 이와 같은 근본적인 설계 선택을 할 때 의사 결정에 주변 .NET 에코시스템을 포함하는 것이 유익한 이유 중 일부입니다.

대체 ORM 다운로드

NuGet 다운로드를 얼핏 보면 비EF 시장 점유율이 어떤 것인지 알 수 있습니다.

최대 절전 모드 - 1M+
멋쟁이 - 100만 이상
OrmLite - 500k+
단순.데이터 - 300k+
페타포코 - ~100k
NPoco - 30k+

Dapper, Massive, PetaPoco, NPoco 등과 같은 많은 Micro ORM이 단일 드롭인 .cs에 맞게 설계되어 NuGet이 실제 사용량을 보고하지 않기 때문에 실제 숫자는 이보다 훨씬 많습니다. 또한 LLBLGen Pro와 같은 폐쇄형 소스 ORM이 있습니다. 이 ORM은 사용자 기반이 크지만 NuGet에서 그 사용법을 보고하지 않습니다.

대체 ORM에 대한 영향

GitHub 덕분에 코어가 포함된 다양한 소스 파일의 수를 빠르게 검색할 수 있습니다.
IDbConnection , IDbCommand 및 IDataReader 이 변경의 영향을 받는 ADO .NET 인터페이스:

참고: 이 결과는 소스 파일만 보여주며, 깨진 참조의 실제 수는 훨씬 더 많습니다.

고객 소스 코드에 미치는 영향

이 변경의 실제 영향은 이러한 ORM을 사용하는 모든 프로젝트 종속성에도 확장됩니다.
불행히도 그 효과는 내부 구현에만 국한되지 않습니다.
많은 Micro ORM의 소스 코드는 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"));

확장 방법 사용의 한 가지 확장 기능은 이러한 ORM이 "개방형"이고 고객이 자체 프로젝트에 확장 방법을 추가하여 자체 일급 API로 ORM을 확장할 수 있다는 것입니다.

분명히 IDbConnection 를 전달하는 모든 소스 코드는 이제 CoreCLR에서 작동하는 것도 금지됩니다.

예를 들어 핵심 ADO.NET 인터페이스는 다중 RDBMS 데이터 액세스를 가능하게 하는 최소 종속성 때문에 채택된 ServiceStack과 같은 고급 프레임워크 전반에 걸쳐 많이 사용 됩니다. 또한 변경될 가능성이 거의 없는 모든 클래스 중에서 핵심 ADO.NET 인터페이스가 될 것이라고 가정했습니다.

요약

저는 개인적으로 이러한 인터페이스가 없는 .NET의 미래가 있다는 사실에 놀랐습니다.
인터페이스는 다중 구현을 허용하도록 설계 목적에 따라 다르며 ADO.NET은 하나입니다.
.NET에서 가장 중요한 "공개 공급자 모델" 중 하나입니다. 어떤 우선 순위로 인해 이러한 인터페이스가 제거되었는지는 모르겠지만 대체 EF .NET 에코시스템과 함께 이러한 인터페이스에 의존하는 기존의 방대한 .NET 코드 기반 모두에 훨씬 더 높은 우선 순위를 부여해야 합니다. 이로 인해 상당한 중단이 발생하고 기존 .NET 4.x 및 CoreCLR 플랫폼을 모두 지원하는 데 필요한 주요 장벽이 되어 이에 의해 영향을 받는 모든 기존 코드 기반에 적용해야 하는 사소하지 않은 추가 복잡성이 발생합니다.

현재 인식은 ADO.NET/CoreCLR이 EF 및 SQL Server에 대한 최고 수준의 지원을 제공하도록 재설계되고 나머지 에코시스템은 무시된다는 것입니다. 이와 같은 불투명한 결정을 내리는 것은 이 고정관념을 다시 시행하기 위한 것일 뿐입니다. .

.NET 팀의 이전 멤버(현재 Roslyn에서 일하고 있음)로서 저는 SQL 및 Entity Framework 팀과 함께 새 데이터 공통의 원래 디자인에 크게 참여했습니다. 지금은 관여하지 않지만 트위터와 그 이상에서 보고 있는 일부 진술을 수정하는 데 도움이 되도록 배경을 추가할 수 있습니다.

.NET Core용 System.Data.Common의 현재 디자인은 우리가 소스를 공개하기 약 2년 전인 2012년 12월에 시작되었습니다.

목표:

• .NET Core에 대한 최신 노출 영역을 설계하여 개념의 중복( IDbConnection vs DbConnection ), 혼동, 실수 및 계층화 문제(DataCommon에서 SqlClient 분할, 핵심 추상화에서 DataSet 분할)를 줄입니다. .NET 1.0의 원래 디자인. 기존 소비자와 _new_ 개발자 모두 .NET Framework에 쉽게 선택할 수 있는 것입니다.
• 공급자와 소비자가 .NET Core에 대해 단일 바이너리/소스를 빌드한 다음 .NET Framework에서 동일한 바이너리를 실행할 수 있습니다. 참고로 반대는 목표가 아니었습니다. .NET Framework 바이너리/소스를 가져와 .NET Core에서 일부 변경 없이 실행할 수 있습니다.

주변에 퍼지고 있는 몇 가지 수정:

• 현재 상태의 인터페이스는 버전 관리가 불가능합니다. 우리는 인터페이스에 멤버를 추가할 수 없으며, @mythz가 확장 메서드를 통해 제공한 위의 제안은 공급자가 어쨌든 추상 기본 클래스에서 파생되도록 요구합니다.
• System.Data.Common은 _제공자 모델에서 벗어나지 _않습니다_. 인터페이스는 .NET 2.0에 도입된 추상 기본 클래스로 대체/복제된 레거시 .NET 1.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 인터페이스에 구성원을 추가하는 것이 좋지 않습니다. 완전히 제거해도 괜찮습니까?

자사 및 타사가 .NET Core에 대해 빌드하고 .NET Framework에서 변경 없이 이식성을 실행할 수 있도록 .NET Core의 노출 영역은 .NET Framework와 바이너리 호환되어야 합니다. 인터페이스에 구성원을 추가하면 해당 구성원의 소비자가 .NET Framework에서 실행될 때 실패하므로 이를 위반합니다.

나는 이러한 인터페이스의 제거 또는 추가를 주장하는 것이 아니라 디자인이 현재 위치에 있는 이유에 대한 배경을 추가하고 싶었을 뿐입니다. @YoungGah 및 @saurabh500을 포함한 현재 소유자가 해결하도록

스레드를 요약하자면 Microsoft가 이러한 인터페이스를 이식해야 한다고 생각하는 이유는 에코시스템이 .NET Framework 구현을 유지하면서 .NET Core로 쉽게 이식할 수 있도록 하기 위해서입니까?

생태계가 .NET Framework 구현을 유지하면서 .NET Core로 쉽게 이식할 수 있도록 하는 것입니까?

예.

스레드를 요약하자면 Microsoft가 이러한 인터페이스를 이식해야 한다고 생각하는 이유는 에코시스템이 .NET Framework 구현을 유지하면서 .NET Core로 쉽게 이식할 수 있도록 하기 위해서입니까?

예. 이제 내 코드베이스(LLBLGen Pro)를 corefx로 이식하면 외부 API가 손상됩니다. 그런 다음 2개의 api를 노출하거나 모든 사용자의 기존 코드베이스를 손상시켜야 합니다.

당신이 고통을 느끼지 않기 때문에 당신이 우리 물건을 부수는 것이 좋을 수도 있습니다. 우리는 그렇습니다. 그것은 나에게 좋지 않습니다. 나는 도살 된 코드 기반으로 살고 같은 일을하는 2 개의 API를 유지하거나 괜찮다고 생각했기 때문에 내 사용자의 코드를 깨야합니다.

나는 또한 인터페이스가 버전이 지정되지 않는 이유를 이해하지 못합니다. 클래스에도 인터페이스가 있는 것처럼 인터페이스일 뿐입니다. CoreFX는 인터페이스에 비동기 메서드를 완벽하게 추가할 수 있습니다.

자사 및 타사가 .NET Core에 대해 빌드하고 .NET Framework에서 변경 없이 이식성을 실행할 수 있도록 .NET Core의 노출 영역은 .NET Framework와 바이너리 호환되어야 합니다. 인터페이스에 구성원을 추가하면 해당 구성원의 소비자가 .NET Framework에서 실행될 때 실패하므로 이를 위반합니다.

쉬운 솔루션: 인터페이스를 있는 그대로 추가하십시오. 그리고 위의 이 규칙이 실제로 다소 어리석다는 것을 모두 느끼면 오래 전에 인터페이스에 추가하는 데 필요한 메서드를 인터페이스에 추가하고 계속 진행할 수 있습니다.

나는 위와 같은 규칙이 서류상으로는 훌륭하지만 실제로는 중요한 MS 팀이 이를 깨야 하는 순간에 깨질 수 있을 만큼 충분히 오랫동안 MS 소프트웨어를 사용합니다. CoreFX 마케팅/홍보에서 말하는 것처럼 '개방적'이고 '다르다면' 보여주세요. System.Data 및 CoreFX와 관련하여 내가 볼 수 있는 것은 'MS가 필요로 하는 것은 완료되고 다른 모든 사람이 필요로 하는 것은 백버너에 있거나 무시됩니다'입니다.

내가 언급하는 것을 잊은 또 다른 것: Fowler는 어제 Twitter에서 모든 사람이 자신의 물건을 이식해야 한다고 언급했습니다. 500K LoC 코드베이스를 CoreFX로 직접 이식하는 데 비용을 지불해야 하며 시간과 노력이 필요하며 다른 기능을 사용하는 데 시간이 걸릴 것입니다. 완전히 인공적인 추가 마찰(새로운 플랫폼입니다! 어떻게 제한적인 규칙이 있을 수 있습니까?)은 실제로 전혀 도움이 되지 않습니다. 추가 유지 관리 비용이 추가되고 코드를 이식하고 테스트하는 데 추가 시간이 걸리며 사용자에게 추가 부담이 됩니다.

그것은 모두 당신의 범위를 벗어나고 당신의 관심사가 아닌 것 같습니다. 하지만 한 가지 잊어버렸습니다. 우리가 코드를 이식하지 않고 더 많은 사람이 나와 함께 한다면? 나는 당신의 새로운 빛나는 프레임워크에 내 큰 코드베이스를 이식하기 위해 시간과 내 자신의 돈을 기꺼이 투자할 의향이 있습니다. . Iow: 나는 매우 외로웠고 동시에 당신은 우리가 당신의 새로운 반짝이는 프레임워크를 좋아하기를 간절히 바라는 것처럼 보입니다.

내가 오래 전에 말했듯 이: 이 프레임워크, 이 새로운 CoreFX를 나에게 판매하십시오. 글쎄, 마찰을 유지하고 많은 이동 및 제거 치즈를 도입하는 것은 여기에 많은 시간(및 돈)을 투자할 큰 인센티브를 생성하지 않습니다.

그냥 내 2센트.

@FransBouma 이 대화를 전문적이고 생산적이며 사실에 초점을 맞추도록 합시다.

나는 인터페이스를 추가하는 것에 대해 찬성하거나 반대하는 것이 아닙니다. 그러나 인터페이스에 메서드를 추가하는 것은 호환되지 않습니다. 다음과 같이 살펴보겠습니다.

1) .NET Core에 IDbConnection.OpenAsync 추가
2) 이 방법을 호출하는 사람은 이제 .NET Framework에서 실행에 실패합니다(위에서 언급한 핵심 원칙/목표 위반). 이것은 또한 XAML 디자이너와 바로 이 사실에 의존하는 몇 가지 다른 VS 기능을 손상시킵니다.
3) .NET Framework를 최신 상태로 만들기 위해 IDbConnection.OpenAsync가 포함된 새 버전의 .NET Framework "4.7"을 제공합니다.
4) 이 메서드를 추가하기 전에 IDbConnection을 구현한 모든 단일 유형이 이제 .NET Framework "4.7"에서 로드되지 않습니다.

이것이 인터페이스에 메소드를 추가할 수 없는 이유입니다.

MS와의 커뮤니케이션 문제와 관련하여 상황이 어떻게 진행되는지에 대한 좌절감을 계속 유지하면 모두가 그것에 대해 알지 못하고 모든 것이 장미와 무지개라고 생각할 것입니다. 그것이 비전문적으로 보이더라도 MS가 내가 전문가라고 생각하는지 여부는 신경쓰지 않습니다.

즉: 나는 인터페이스와 결혼하지 않았으므로 인터페이스가 사라지면 그때부터 클래스가 있고 이론적으로 작업할 인터페이스가 없다는 사실이 나를 슬픈 팬더로 만들지 않습니다. 해야 할 일 오늘날 모든 주요 ADO.NET 공급자가 훌륭하게 작동하고 기본 클래스에서 파생되기 때문에 오늘날 기본 클래스를 통해 이론상으로 수행해야 합니다. 기본 클래스에서 파생됨). 이것은 내가 이 스레드의 앞부분에서 처음에 그것들을 제거하는 것이 큰 문제라고 생각하지 않은 이유이기도 합니다. 그 이후로 나는 그것에 대해 생각할 시간이 있었고 나는 그것이 _큰 일이라고 생각합니다.

우리는 화성의 진공 상태에 살고 있지 않으며 스택 맨 아래에 있는 미들웨어/프레임워크에는 현재 문제가 있습니다. 이러한 프레임워크의 현재 .NET 정식 버전 사용자는 이러한 프레임워크를 알고 있기 때문에 CoreFX에서 계속 사용하기를 원합니다. 그러나 CoreFX로 포팅하는 것은 수많은 이유 때문에 큰 PITA입니다. 그 중 하나는 CoreFX에 없는 공개 API에 노출된 인터페이스로 자주 사용됩니다(이 스레드의 이유).

그 이유만으로도 인터페이스를 다시 보고 싶습니다. 저에게는 개인적으로 기술적인 이유가 아닙니다(예: 비동기에는 기본 클래스가 필요합니다. 이미 엉망입니다). 나는 그들이 특정한 방법이 없다는 것을 알고 있지만 그것은 당신의 문제이지 내 문제가 아닙니다. 그것들을 제거하면 내 문제가되고 (지금 바꿔 말하면) MS 응답은 "할 수 없습니다!"로 손을 던지십시오. 하지만 나에게는 그런 사치가 없다. 당신이 이 난장판을 만들었고, 당신이 해결했습니다. 당신은 내가 당신의 새로운 프레임워크를 지원하기 위해 내 코드를 이식하고 많은 시간과 돈을 투자하기를 원합니다.

4단계 시나리오를 살펴보면 CoreFX를 별도의 프레임워크로 보는 경우 인터페이스에 메서드를 추가하는 것이 문제가 되지 않습니다. 그리고 어쨌든 그렇지 않습니까? 그것은 몇 년 전 Compact Framework와 동일합니다(내 프레임워크를 이식했고 CoreFX로 이식하는 것이 간단하고 빠르며 쉽지 않고 두 개의 코드 기반을 유지하는 것이 아니라는 몇 가지 어려운 교훈을 배웠습니다. 둘 중 하나도 아님): 우리는 1개의 API로 시작한 다음 누군가가 무언가를 잊어버렸거나 MS 내의 일부 팀이 무언가를 필요로 합니다.

(예: Compact Framework는 'SerializableAttribute'를 잊어버렸습니다. 그들은 이후 버전에서 아무 것도 하지 않는 더미 속성과 함께 추가했지만 존재하지 않을 것으로 예상하고 자체적으로 정의한 코드를 깨뜨렸습니다)

하지만 도로를 나누는 것은 이해할 수 있습니다. 호환성을 유지하려고 하는 것은 너무 제한적입니다. 나는 이 규칙이 미래에 깨질 것이라고 지금 여기에서 예측합니다.

사물을 '호환성'으로 보는 것은 API 서명 수준뿐만 아니라 API _동작_ 수준에서도 중요합니다. API 동작에서 이 둘(CoreFX 및 .NET Full)이 완전히 동일할 것이라고 믿는 것은 너무 위험합니다. 프레임워크 개발자는 CoreFX 및 .NET 전체에서 동일한 기능을 테스트해야 하므로 CoreFX 단독 테스트는 불가능합니다. 코드가 향후 .NET 전체에서 100% 동일하게 작동한다고 가정하기에 충분합니다. 어떻게 보장할 수 있습니까? CoreFX에 대한 심층적인 호출 스택 20 호출은 .NET 전체에서보다 훨씬 더 많은 다른 코드를 건드렸고 여기저기서 작은 세부 사항과 상황이 변경되었습니다.

이 모든 것의 요점은 별도의 프레임워크입니다. CoreFX에 대해 컴파일된 코드는 .NET 전체에 대해 컴파일된 코드와 다를 수 있습니다.

몇 가지 상황이 있습니다.

1) 프레임워크에는 CoreFX에서 100% 컴파일되는 코드 기반이 있습니다. 이것은 .NET 전체에서 실행할 수 있는 dll을 제공합니다.
2) 프레임워크에는 CoreFX에서 70% 컴파일되고 .NET 전체에서 100% 컴파일되는 코드 기반이 있습니다. 이렇게 하면 CoreFX용과 .NET 전체용의 2개의 dll이 제공됩니다. .NET 전체에서 CoreFX 버전을 실행하는 것은 기능의 30%를 놓치기 때문에 어리석은 일입니다.

1)의 경우 귀하의 요점을 이해합니다. 2)의 경우(현재의 모든 .NET 전체 대상 프레임워크, 그 중 _all_ 타사 ORM의 경우) 2개의 dll과 함께 작업해야 하므로 요점은 실제로 의미가 없습니다. 별도로 유지 관리하고 별도로 테스트하고 자체 새 버전으로 별도로 마이그레이션합니다. 특히 CoreFX가 아직 .NET 전체의 일부가 아닌(이 경우도 마찬가지임) 새로운 기능을 얻는 경우. (btw: DataTable과 다른 데이터 구조를 반환하는 CoreFX에 DbDataReader.GetSchemaTable()을 추가하면 MS가 이식을 거부하기 때문에 CoreFX에서 DbDataReader.GetSchemaTable을 사용하는 코드는 .NET 전체에서도 중단됩니다. 이름을 다르게 지정하면 메서드가 없을 뿐 아니라 깨질 것입니다. Iow: _both_ 프레임워크에 없는 것이 사용되면 코드가 깨집니다. 그렇다고 해서 CoreFX에 존재하지 않아야 한다는 의미는 아닙니다.

CoreFX에 인터페이스가 없다는 것은 상황 2)의 프레임워크 상황을 영구적인 것으로 만듭니다. 예를 들어 API가 인터페이스를 노출하기 때문에 1)에 맞는 프레임워크가 되도록 이동할 수 없습니다.

Microsoft는 상황 1)에서 프레임워크가 프레임워크가 되도록 자체 항목을 다시 작성하는 것이 좋습니다. 그러나 우리에게는 백만 달러의 예산이 없고 ORM 런타임에 15명 이상의 사람들이 있고 우리 측의 주름을 부드럽게 할 대규모 PR 기계가 없습니다. 모든 앱을 깨고 있습니다. 따라서 우리는 2)에 갇혀 있거나 1)으로 이동하기 위해 MS의 약간의 도움이 필요합니다.

이것이 바로 여기에서 문제가 되는 것입니다. 당신은 트위터에서 "필요한 것을 말해주세요"라고 말했습니다. 우리는 했다. 자꾸. 특히 System.Data에 관해서는 통신이 없습니다 . 아무것도. 미래 계획도 없고, 무엇을 해야 할지 논의도 없고 막다른 골목에 있으며 때로는 MS 직원이 개입하면 문제에 진정한 이해 관계가 없는 사람입니다. 시간을 할애해 주셔서 감사합니다. 배경이 많을수록 더 좋아지지만 동시에 동료와 이 문제에 대해 이야기하는 것과 같습니다. 담당자가 부재 중이고 부재중이어서 해결되지 않습니다. 토론에 참여.

그것이 나를 좌절하게 만들고 신이 '비전문가'를 금지한다면 그렇게 하십시오.

듣기 주셔서 감사합니다. Btw 나는 환상이 없습니다 wrt System.Data: 코드를 포팅하는 것은 API의 난파선이 될 것이며 API 위에 핵심 프레임워크를 작성하는 개발자와 연락이 없기 때문에 희망 사항이 거의 또는 전혀 없습니다. 바뀔 것이다. 당신의 잘못이 아닙니다. @davkean , 개인적인 것이 아닙니다.

나는 의사 소통의 부족에 대한 위의 좌절감을 되풀이해야합니다. 대량 삽입 및 스키마 정보도 필요합니다. 이러한 누락된 코어(양방향 모두) 기능은 한 달 넘게(dotnet/runtime#15269 및 dotnet/runtime#14302 참조) 발전이나 커뮤니케이션이 없었습니다. 그러나 Microsoft는 현재 코드를 "출시 후보"로 지정하고 있으며, 그 자체가 "충분히 좋습니다"라는 메시지입니다. 그렇지 않다. 추가해야 할 핵심 사항이 누락되었으며 이러한 스레드를 따르는 경우 유사한 버전 관리 이유로 첫 번째 버전 에

dotnet/runtime#14302("DataTable/View/Set Absent가 있는 이유는 무엇인가요?")의 마지막 업데이트를 보면 22일 전에 다음과 같이 묻습니다.

이제 CoreCLR의 V1에 대한 System.Data.Common 기능이 완성되었습니까?

예, 좌절은 비전문으로 보일 수 있습니다. 텍스트의 어조와 맥락은 형편없고 항상 그렇습니다. 그러나 여기에서 우리는 그것이 제한됩니다. 나는 모두가 여기에서 생산적인 일을 하려고 노력하고 있다고 생각하지만, 우리는 System.Data 영역의 실제 진행 상황에 대해 CoreFX 측에서 꽤 많은 벽을 허물고 있습니다. 그리고 이 비트의 사용자.

우리는 이러한 핵심 기능 조각, 인터페이스가 필요합니다. 저는 인터페이스에 대해 엄격하지 않으며 인터페이스 없이 Dapper를 이식했습니다. 그러나 DataTable의 부족, 결과 스키마 정보, 대량 삽입 등은 "릴리스 후보"에서 허용되지 않습니다. Microsoft는 현재 코드에 RC로 레이블을 지정하는 것에 대한 불만을 증가시키는 사람입니다. 현재 코드가 출시될 준비가 되지 않았다는 데 거의 보편적으로 동의하고 있습니다. 네, 그냥 레이블입니다. 하지만 잘못된 레이블이자 임의의 일정(현실을 반영하도록 변경되어야 함)에 기반하기 때문에 긴급도를 크게 높이는 레이블입니다. 이 스레드의 누구도 그 일정에 책임이 있다고 생각하지 않지만 _level_ 좌절의 주요 요인으로 언급할 가치가 있습니다.

근본 문제로 돌아가자. 우리는 이러한 조각이 필요하며 수백만 명의 사용자가 필요합니다. 수정하겠습니다.

1백만 개 이상의 다운로드로 NHibernate를 잊지 말자:

| 아이디비커넥션 | IDb명령 | IDataReader |
| --- | --- | --- |
| 59 | 181 | 132 |

현재 인식은 ADO.NET/CoreCLR이 EF 및 SQL Server에 대한 최고 수준의 지원을 제공하도록 재설계되고 나머지 에코시스템은 무시된다는 것입니다. 이와 같은 불투명한 결정을 내리는 것은 이 고정관념을 다시 시행하기 위한 것일 뿐입니다. .

그 인식은 다음과 같은 것들에 의해 강화됩니다: https://github.com/dotnet/corefx/issues/4646

내가 말할 수 있는 한, SqlClient 어셈블리 외부에서 유용한 방법으로 해당 API를 구현하는 방법 은 없습니다.

저는 현재 인터페이스 없이 테스트하는 데 문제가 없습니다. 그러나 솔직히 인터페이스 버전 관리 및 호환성에 대한 추론을 이해하지 못합니다.

.NET Core의 아이디어는 호환성에 대한 부담이 없는 새로운 프레임워크이며 애플리케이션과 함께 번들로 제공되므로 그런 문제를 처리할 필요가 없다는 것이 아닙니까? 공급자는 스키마 및 데이터 테이블과 같은 항목이 없기 때문에 이미 .NET의 공급자와 호환되지 않습니다. 그렇다면 호환성이 손상되는 것은 무엇입니까? 인터페이스가 변경되면 새 버전에 대해 컴파일하고 앱과 번들로 묶으면 됩니다.

디자인에 대한 대부분의 핑계는 새 프레임워크에 적용할 수 없는 기존 프레임워크의 걱정거리인 것 같습니다. 어쨌든 실제로 어떻게 되는지 봅시다.

여러 프레임워크를 지원하고 역사적으로 인터페이스를 목표로 삼고 있는 사용자를 위해... 저는 Dapper가 사용하는 추악한 더미를 공유하고 싶습니다. 이것이 _good_이라고 말하는 것은 아니지만 컴파일하기에는 충분합니다. 물론, 그것은 엄청난 파일 더미에 복제됩니다... 저는 주로 또 다른 영향을 강조하기 위해 이것을 공유하고 있습니다.

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

인터페이스에 구성원을 추가할 수 없습니다.

맞습니다. 인터페이스의 _좋은_ 기능입니다. 추상 기본 클래스에 대한 기본 설정은 API 엔트로피와 싸우는 대신 API 엔트로피를 돕는 가장 안전한 방법입니다.

OOD 원칙 을 따라야 _하지_는 않지만 OO API를 만들 때 수행하는 것이 좋습니다. 간단히 말해서 ISP( 인터페이스 분리 원칙 )는 _어떤 클라이언트도 사용하지 않는 메서드에 강제로 의존해서는 안 된다고 명시합니다.

기존 추상화에 새 메서드를 추가하면 자동으로 ISP를 위반하게 됩니다.

당신은 Microsoft이고 BCL로 작업하고 있기 때문에 'SOLID를 고수할 필요가 없다'고 결정할 수 있습니다. 반대 주장).

6-7년 동안 몇 개의 오픈 소스 프로젝트를 유지해 온 경험상 인터페이스를 작게 유지하는 것이 좋습니다. 추상화에 새로운 기능을 추가해야 하는 경우 새 인터페이스를 도입하세요.

• " 구현이 아닌 인터페이스에 프로그래밍하십시오. "
• " 클래스 상속보다 객체 합성을 선호합니다. "

여기에 찬성 투표가 있었다면 @ploeh 님 의 의견에 +1000을

평소와 같이 @ploeh의 통찰력있는 의견.

@FransBouma , 우리는 전체 프레임워크를 손상시키지 않는 방식으로 DbDataReader.GetSchemaTable()의 대체 기능을 추가할 것입니다.
@NickCraver , SqlBulkCopy는 우리의 미래 계획에 있으며 스키마에 대해 작업 중입니다. 우리는 또한 x-플랫폼에서 작동하도록 스택을 만드는 데 합리적인 진행을 해야 하기 때문에 스키마에 대한 진행이 느립니다.
@mythz , 고객 영향에 대한 예제, 숫자 및 평가를 제공해 주셔서 감사합니다. 우리는 그들을 검토할 것입니다.

@YoungGah 정보와 관련된 문제를 업데이트하여 이러한 문제가 최신 상태로 유지되도록 하십시오( 예:

@FransBouma 예, 다른 스레드도 업데이트하겠습니다. 언제 그리고 무엇을 사용할 수 있는지에 대한 추가 정보에 대한 귀하의 요청과 관련하여 귀하가 필요로 하는 이유를 충분히 이해합니다. 기능/기능을 v1에서 사용할 수 있는지, 의도적으로 제거되었는지, v1 이후에 사용할 수 있는지 또는 향후 사용 가능성에 대한 디자인이 보류 중인지 여부를 나타내는 목록을 게시할 것입니다. 앞으로 2주동안 포스팅하도록 노력하겠습니다. DbDataReader에 대한 스키마 가져오기 기능과 DbConnection 기능에 대해서는 rc2 릴리스에서 사용할 수 있도록 할 계획입니다. 예측할 수 없는 이유로 계획이 변경되는 경우 커뮤니티를 업데이트합니다.

여기에서 무슨 일이 일어나고, 나중에 참고할 수 있도록 @YoungGah; IDataReader에는 DataSet에 대한 종속성이 있는 DataTable에 대한 종속성이 있습니다(우리는 별도의 계층으로 간주합니다. 정책이 없는 이러한 유형과 달리 정책이 무겁기 때문에). 따라서 이러한 인터페이스가 다시 가져.

@ploeh 의 접근 방식에 대해 여기에 다른 투표를 하고 싶습니다. 인터페이스가 있지만 현재 BCL에 있는 대부분의 인터페이스보다 훨씬 더 세분화되어 있습니다. 이것은 분리와 버전 관리에 대한 @davkean 의 의견을 모두 다룹니다.

이전 인터페이스를 상속하는 새 인터페이스를 가질 수 없는 이유는 무엇입니까? 오래된 것을 폐기하십시오. 앞으로 오래된 것을 제거하십시오. 적어도 확장하고 기존 사용을 중단하지 않을 수 있습니다.

또는 여러 개의 작은 인터페이스. 댓글을 달게 되었습니다.

원본 .NET과의 완벽한 호환성이 필요하다는 것을 이해하지 못합니다. 여기서 끊을 것이 없습니다. 이것은 새로운 프레임워크이며 레거시 코드와의 관계를 끊고 오랫동안 필요하지만 원래 프레임워크에서 손상될 수 있는 변경 사항을 적용할 수 있는 완벽한 기회입니다.

인터페이스를 다시 제안했을 때 원래 1.1 인터페이스를 가져올 생각이 아니라 새로운 디자인으로 인터페이스를 업데이트했습니다. @ploeh가 말했듯이 더 많은 것이 있을 수 있습니다.

인터페이스는 가능하면 레거시 지원이 가능하지만 이 시점에서 우선순위가 되어서는 안 됩니다.

이 주제에 많은 관심이 있어서 재개합니다.

여기서 끊을 것이 없습니다. 이것은 새로운 프레임워크이며 레거시 코드와의 관계를 끊고 오랫동안 필요하지만 원래 프레임워크에서 손상될 수 있는 변경 사항을 적용할 수 있는 완벽한 기회입니다.

그렇다면 원래 잘못 설계된 인터페이스를 제거하고 ADO.NET과 같은 기본 클래스에서 표준화할 수 있는 완벽한 기회가 이미 이루어지고 있습니까? :트롤페이스:

진지하게 말하지만 깨끗한 API 또는 이전 버전과의 호환성 중에서 선택할 수 있습니다. 하나를 선택. 나는 당신의 케이크를 가지고 그것을 먹는 방법을 볼 수 없습니다.

@JamesNK 하지만 그게 정확히 요점입니다. 이전 버전과의 호환성은 필요하지 않습니다.

농담이지만 ​​인터페이스가 있는 잘못 설계된 API는 인터페이스가 아니라 잘못 설계되었기 때문에 나쁜 것입니다. =) 인터페이스가 NET의 모든 곳에서 절대적으로 사용되지 않거나 이것은 새로운 것이 아닙니다. 이번에는 올바르게 디자인하고 계속 진행하십시오.

ADO.NET은 모든 .NET에서 가장 안정적인 코드 중 하나입니다. 15년 동안 두세 차례의 심각한 변화가 있었습니다. 인터페이스에 안정화되고 모두를 위해 더 간단하게 만드는 완벽한 API입니다.

참고로 이 주제 는 가장 많이 언급된 문제 중 하나이며 인터페이스 대 가상 메서드, 테스트 가능성 및 기타 항목에 대해 오랫동안 동일한 토론을 했습니다.

@nvivo 나는 혼란 스럽습니다. 기본 클래스가 테스트 가능성을 활성화한다는 것을 확인한 후 이 스레드는 .NET Framework 코드를 .NET Core로 이식할 수 있도록 인터페이스를 다시 가져오는 것으로 변경되었습니다. 인터페이스를 재설계하고 새로운 것을 도입하면 어떻게 도움이 될까요?

왜 우리는 이전 버전과의 호환성을 위한 독창적인 인터페이스를 가질 수 없고 당신이 선택한 무엇이든(추상 클래스 또는 작은 인터페이스) 앞으로 나아갈 수 없습니까? 원래 인터페이스는 새 스택의 맨 위에 있고 이전 버전과의 호환성을 제공할 수 있습니다. 이 부분도 선택 사항이 될 수 있습니다.
그것은 이식을 쉽게 만들고 여전히 새로운 방법을 허용합니다.

@davkean

여기에 댓글을 다신 모든 분들에게 답변을 드릴 수는 없습니다. 나는 새로운 현재 API로 업데이트된 ADO.NET의 API로 인터페이스를 사용할 것을 제안했습니다. 원래 인터페이스와 모든 문제를 가져오라고 요청하지 않았습니다. 목적은 API를 보다 명확하게 정의하고 API를 조롱하고 이에 의존하는 코드(대부분 사용자 코드가 아닌 데이터 추상화 라이브러리)를 테스트할 수 있도록 하는 것이었습니다.

@ploeh가 현명하게 말했듯이 인터페이스는 API를 설명하는 데 더

이제 클래스가 이미 어떻게 나쁜 디자인을 만들고 있는지 보기 위해:

• DbCommand에 DesignTimeVisible 속성 이 있는 이유는 무엇입니까? 디자인 타임 지원이 연결로 정의되는 연결에 대한 요구 사항입니까?
• 상태 변경 을
• ConnectionStringBuilder 는 공급자가 존재하기 위한 요구 사항입니까? 아니면 VS 마법사가 기본적으로 작동하도록 하는 더 좋은 방법이 있습니까?
• DbDataReader 가 일부 핵심 유형에 대해 Get 메소드를 정의하지만 GetByteArray() 및 GetDateTimeOffset() 와 같은 다른 유형에 대해서는 추가하지 않는 이유는 무엇입니까? 문자열이나 스트림을 사용하여 외부에서 수행할 수 있는 경우에도 TextReader를 검색 해야 합니까? 이것이 인터페이스라면 이와 같은 메소드가 API에 추가되거나 구체적인 클래스(예 GetSql* SqlDataReader의

이것들은 모두 수사학적 질문입니다. 나는 그들 모두가 설득력 있는 답변을 가지고 있고 모든 것을 고려했다고 확신합니다. 요점은 현재 디자인이 분명히 API 정의로 생각되었던 것이 아니라 인터페이스에서 더 많은 관심을 받을 것이라는 점입니다.

솔직히, 외부에서 디자인에 대한 논의는 다음과 같이 들립니다.

• Visual Studio의 마법사가 기본적으로 작업하는 것이 더 쉽기 때문에 이러한 이벤트를 여기에 유지하겠습니다.
• 우리는 EF를 가지고 있고 그것이 전 세계 모든 사람들이 사용해야 하는 것이기 때문에 스키마 검색 방법을 제거합시다.
• .NET 1.1부터 지원되고 호환성을 깰 수 없기 때문에 이러한 편리한 방법을 유지합시다!
• 데이터 테이블과 데이터 세트를 제거하고 .NET 1.1에서 오는 모든 사람이 어쨌든 전체 코드베이스를 변경하도록 합시다!
• 클라우드 컴퓨팅, 커뮤니티, 오픈 소스 및 미래의 애플리케이션에 중점을 둔 새로운 공급자 모델을 구축합시다...
• ... 그리고 SqlClient를 _sole_ 테스트 케이스로 사용하여 어제의 요구 사항을 기반으로 이 모델을 빌드해 보겠습니다!
• 각 응용 프로그램과 함께 번들로 제공되는 완전히 새로운 프레임워크를 구축해 봅시다. 그러면 아무도 업데이트가 자신의 응용 프로그램을 _다시는_ 중단하는 것에 대해 걱정할 필요가 없습니다!
• .. 그런 다음 변경 사항으로 인해 업데이트가 중단될 수 있으므로 인터페이스를 추가하지 않기로 결정합시다!

예, 거기에는 약간의 호언장담이 있고 이 토론은 아무데도 가지 않고 있습니다 =)... 하지만 이것을 내 가슴에서 꺼내고 싶었습니다. 2015년, 모든 것이 항상 깨지고 우리는 그것에 익숙해져 있습니다. ADO.NET의 인터페이스 변경 사항보다 훨씬 더 많은 주요 변경 사항을 야기할 ASP.NET MVC에 대한 20개의 업데이트가 향후 몇 년 동안 있을 것입니다.

저는 여전히 .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

이게 문제 야; 고려된 접근 방식보다는 임의의 마감일을 맞추기 위해 급하게 다시 작성하고 있습니다.
필요한 경우 4/16에 늦는 것이 반짝이는 새 깨진 쓰레기를 얻는 것보다 빠를 것입니다. 2015년이고 모든 고장은 끔찍한 정당화입니다.

@thefringeninja 는 시스템의 절반(공유의 경우)에서만 작동하는 완전히 불필요하고 혼란스러운 종속성을 추가하거나 extern alias 를 선택 해제해야 하는 이름 충돌로 이어집니다. a System.Data.IDbConnection 은(는) 다르지만 동일한 System.Data.IDbConnection 를 제공하지 않습니다. 기본적으로, 그것은 상황을 10배 더 악화시킬 것입니다.

@mgravell 의 구체적인 예를 들어 Type.GetType("System.Data.IDbConnection, System.Data") 을 사용하거나 PCL 시나리오에서 이것이 어떻게 중단되는지 알 수 있습니다.

orm A가 System.Data.IDbConnection을 정의하고 orm B가 정의하는 경우
System.Data.IDbConnection, 이제 완전히 다른 두 가지가 있습니다.
동일한 이름/네임스페이스, 충돌 및
실제로 DB 제공자에서 작동하지 않습니다. 그것은 아무것도 해결하지 않습니다,
원래. 더 나쁜 점: 누군가가 통과할 것으로 예상되는 사용할 수 없는 API를 임대합니다.
SqlConnection 또는 NgpSqlConnection에서 - 작동하지 않습니다.

실제로 이를 위한 오픈 소스 코드 패키지를 만들고 공유할 수 있습니다.

System.Data.Common이 아니면 DbConnection이 이를 구현하지 않는다는 의미이며, 신경 쓰지 않아도 됩니다.

모든 ORM 또는 ADO .NET 공급자 유지 관리자가 외부 제3자 종속성(SQL Server는 거의 보장하지 않음)을 취하는 것에 대한 합의를 얻지 못할 것이며 핵심 BCL 인터페이스를 재정의하는 2개의 라이브러리는 함께 사용할 수 없습니다. Core libs(이제 정의해야 함)에서 System.Data 인터페이스를 참조하는 상위 수준 프레임워크(예: ServiceStack)에서는 더 이상 동일한 인터페이스를 참조하지 않는 ORM을 사용할 수 없습니다. - 하거나 해야 합니다.

모든 라이브러리가 동일한 System.Data 인터페이스를 참조하도록 할 수 있는 유일한 방법은 인터페이스를 구현하는 기본 클래스로 복원된 경우입니다. 이것이 어떤 피해를 주는지 아직 확실하지 않습니다.

@mgravell 아 전이 종속성, 그것을 고려하지 않았습니다. :+1:

소유하지 않은 코드에 코드를 긴밀하게 연결하지 않는 한 이것이 왜 문제인지 알 수 없습니다. 종속성으로부터 코드를 보호하십시오! 감싸서 추상화하십시오. 이를 수행하고 코드를 테스트 가능하게 만드는 방법에는 여러 가지가 있습니다. 많은 사람들이 위에서 언급되었습니다. 당신은 당신이 소유하지 않은 비트를 통합 테스트합니다. 그것이 작동하는 방식입니다. BCL 객체를 조롱해서는 안됩니다! 그렇다면 디자인이 좋지 않습니다.

@nvivo 이것이 귀하의 원래 문제라는 것을 알지만, 이제 그 방향이 호환성을 위해 v1 시대 인터페이스를 다시 가져오는 것에 대한 스레드로 바뀌었습니다. 그것에 초점을 맞추도록 합시다. 현재 노출 영역을 변경하는 것에 대해 논의하려면 새 문제를 제출하세요.

@mythz 인터페이스에 두 가지 문제가 있습니다. 1) 정책 없는 추상화에 속하지 않는 DataSet에 대한 (무거운) 종속성을 가져왔고 2) 기본 클래스에 병렬 추상화 집합을 가져오지만 v1 노출 영역으로 잠겨 있습니다. 우리는 그 혼란을 피하고 싶었습니다.

제3자가 이러한 인터페이스를 제공하는 것은 실행 가능하지 않다는 데 동의합니다. 유용하려면 핵심 추상화에서 구현해야 합니다.

이것이 귀하의 원래 문제라는 것을 알지만, 그 방향은 이제 호환성을 위해 v1 시대 인터페이스를 다시 가져오는 것에 대한 스레드로 바뀌었습니다. 그것에 초점을 맞추도록 합시다. 현재 노출 영역을 변경하는 것에 대해 논의하려면 새 문제를 제출하세요.

이것은 전혀 말이 되지 않습니다.

@nvivo 그것은 당신이 그것을 제출했음에도 불구하고 문제가 있는 사람이 아니라는 것을 의미합니다. 문제는 System.Data 인터페이스를 복원하여 이에 의존하는 전체 생태계를 지원하는 부담을 줄이는 것입니다. 당신은 괜찮은 것 같습니다:

2015년, 모든 것이 항상 깨지고 우리는 그것에 익숙해져 있습니다.

그러나 이것은 기존 코드 기반과 고객의 코드 기반을 지원해야 하는 우리에게 만족스러운 전략이 아니며 모든 .NET에 영향을 미치는 BCL 라이브러리 관리자를 위한 기본 전략이 아니어야 합니다.

그러나 이것은 기존 코드 기반을 지원해야 하는 우리에게 만족스러운 전략이 아닙니다.

@mythz 이것은 문맥에 맞지 않습니다. 그것은 내가 의도 한 게 아니었다. 여기 있는 모든 사람은 기존 코드 기반을 지원해야 합니다. 토론에 .NET에 새로 온 사람이 있는지 의심스럽습니다.

이 대화가 무엇으로 바뀌었는지 문제는 그것이 별로 의미가 없다는 것입니다. .NET Core는 업그레이드가 아니라 새로운 프레임워크입니다. 기존의 많은 .NET API는 존재하지 않으며 앞으로도 없을 것입니다. 이전 버전과의 호환성은 어쨌든 그렇게 작동하지 않습니다.

@nvivo 이 정확한 감정이 이 문제가 당신에게 적용되지 않는 이유입니다. 이전 버전과의 호환성이 중요하지 않다고 생각한다면 여러 플랫폼을 대상으로 하는 의미 있는 코드 기반 지원을 시도한 적이 없습니다. CoreCLR 팀을 대신하여 말하는 것도 아닙니다. 이러한 라이브러리는 처음부터 개발된 것이 아니므로 위에서 읽으면 CoreCLR 라이브러리가 전체 .NET Framework에서 실행되는 것이 주요 목표라는 것을 알게 될 것입니다. CoreCLR은 .NET 팀이 적극적으로 권장하고 이러한 누락된 인터페이스가 현재 방해하고 있는 기존 라이브러리 이식이 성공에 필수적인 또 다른 플랫폼 대상입니다.

인터페이스가 버전 친화적이지 않다는 이 모든 이야기로 인해 Go 프로그래밍 언어가 암시적 인터페이스로 이 문제를 회피하는 방법에 대해 생각하게 됩니다.

_policy-free_ 추상화의 의미를 확장하라는 요청을 받았습니다.

기본적으로 정책이 없다는 것은 System.Data.Common 추상화에 비즈니스 규칙이 거의 포함되어 있지 않음을 의미합니다. 즉, 주어진 공급자가 구현해야 하는 API 형태를 제공하는 것뿐입니다. 이것은 많은 비즈니스 규칙과 코드가 있는 DataSet과 대조됩니다. 정책이 없는 유형은 매우 구성되어 있기 때문에 정책이 포함된 유형보다 버전 빈도가 낮은 경향이 있습니다. 코드가 적기 때문에 버그와 디자인 변경이 적기 때문입니다. 우리는 대규모 패키지 그래프에서 종속성을 조정할 때 발생하는 문제의 수를 줄이기 위해 타사 라이브러리에서 드물게 버전[2]으로 _교환_[1]되는 추상화 및 유형을 원합니다. 교환 유형은 애플리케이션의 일부로 포함하거나 병합할 수 없지만 비교환 유형은 가능합니다. 따라서 우리가 분할을 원하는 이유.

[1] _exchanged_는 공개 API에 나타나는 경향이 있는 유형을 의미합니다. 예를 들어 Collection<T> 는 교환 유형으로 간주되지만 List<T> 는 고려하지 않습니다.
[2] 이에 대한 의미론적 버전 관리를 사용하면 생태계를 "포크(fork)"하기 때문에 인터페이스가 제거된 위와 거의 동일한 원인 중단이 발생합니다. 라이브러리는 중단 전 또는 후에 라이브러리를 대상으로 할지 또는 분할을 처리하기 위해 자체적으로 분기할지 여부를 결정해야 합니다.

@mythz 상용 앱과 기존 코드의 일부로

인터페이스가 없으면 컴파일러 지시문으로 처리합니다.

오? IDataReader를 반환하는 메서드나 IDbConnection을 받는 메서드는 어떻습니까? 아니면 IDbTransaction? 귀하의 _customers_ 코드가 해당 API를 사용한다면 어떻게 #ifdev를 실행하시겠습니까?

'처리'…그게 무슨 오만이야?

간단합니다. 기본 패키지(조직)를 업데이트하여 고유한 유형 또는 2.0 이후 지원한 기본 유형을 반환합니다. 이전 버전의 .net을 대상으로 하는 경우 지시문을 사용하여 대신 인터페이스를 반환하고 더 이상 사용되지 않는 것으로 표시할 수 있습니다.

예, 그것은 형편없지만, 나는 그들이 (항상 이것에 대해 생각하는 정말 똑똑한 개인들) 그 당시에 합당한 이유 때문에(.net 2.0에서) 그렇게 했다고 확신합니다. 이야기가 나올 수 있고 아마도 이것은 확실히 바뀔 수 있습니다. 그러나 문제는 새로운 런타임으로 업그레이드하는 사람들이 약간의 작업을 수행해야 한다는 것입니다. 멋진 UI에서 버튼을 클릭하는 것이 아니라 작업을 잘라내도록 하는 것입니다. 그러나 동시에 많은 유형을 이동하여 교체하는 것보다 새 프레임워크로 업그레이드하는 것이 더 쉬워야 한다는 데 동의합니다.

@FransBouma 그는 아마도 강력한 네이밍을 옹호하는 사람일 것입니다.

@FransBouma @phillip-haydon은 당신의 트롤링을 다른 곳으로 데려갈 수 있습니다. 당신은 그렇게 행동하고 사람들이 당신을 진지하게 받아들일 것이라고 기대할 수 없습니다. 궁금한 점이 있으면 내 오픈 소스 기여/프로젝트를 살펴보십시오. 나는 이것을 처리해야 합니다... 어느 쪽이든...

참고로 저는 강력한 네이밍에 반대합니다.

받아 들여...

그리고 당신은 내가 트롤링하고 있다고 말합니까?

" @FransBouma 그는 아마도 강력한 네이밍을 옹호하는 사람일 것입니다." 주제에서 벗어났고 이 강연에 별로 도움이 되지 않았습니다. 네 트롤링같은 느낌..

이 논의에서 고려해야 할 한 가지 중요한 사실은 기본 클래스가 도입된 10년 전 .NET 2.0에서 IDb* 인터페이스가 ADO.NET용 API로 더 이상 사용되지 않는다는 것입니다. 더 이상 사용되지 않는 것으로 표시되지는 않았지만 그 이후로 빌드된 모든 것은 기본 클래스에 따라 달라집니다. App.config 공급자 및 연결 문자열 지원이 떠오릅니다.

이러한 인터페이스에 의존하는 코드가 있는 경우 비동기 메서드와 같은 것을 지원하지 않는 매우 구식 API에 대해 코딩하는 것입니다. 즉, 사람들이 계속 사용하기를 원하면 어쨌든 업데이트해야 함을 의미합니다.

간단합니다. 기본 패키지(조직)를 업데이트하여 고유한 유형 또는 2.0 이후 지원한 기본 유형을 반환합니다. 이전 버전의 .net을 대상으로 하는 경우 지시문을 사용하여 대신 인터페이스를 반환하고 더 이상 사용되지 않는 것으로 표시할 수 있습니다.

수천 개의 애플리케이션에서 사용하는 공개 API이며 API는 .net 1.0부터 공개되어 사용 중입니다. 오히려 '단순'하지 않습니다. 우리는 API를 변경할 수 없습니다. Microsoft는 그것이 우리의 삶을 더 좋게 만들기 위해 해야 하는 일이라고 생각하기 때문입니다. 이는 사용자와 우리 모두에게 큰 부담이 될 것입니다.

예, 그것은 형편없지만, 나는 그들이 (항상 이것에 대해 생각하는 정말 똑똑한 개인들) 그 당시에 합당한 이유 때문에(.net 2.0에서) 그렇게 했다고 확신합니다. 이야기가 나올 수 있고 아마도 이것은 확실히 바뀔 수 있습니다. 그러나 문제는 새로운 런타임으로 업그레이드하는 사람들이 약간의 작업을 수행해야 한다는 것입니다. 멋진 UI에서 버튼을 클릭하는 것이 아니라 작업을 잘라내도록 하는 것입니다. 그러나 동시에 많은 유형을 이동하여 교체하는 것보다 새 프레임워크로 업그레이드하는 것이 더 쉬워야 한다는 데 동의합니다.

그것이 바로 '새로운 런타임'으로 보이지 않는다는 것입니다. 이미 논의한 것처럼 그런 경우라면 문제가 되지 않을 것입니다. 그러나 Microsoft는 dll을 대상으로 하는 CoreFX가 .NET 전체에서도 작동해야 한다는 생각을 가지고 있으므로 새로운 프레임워크가 없습니다. .NET 전체를 대상으로 하는 라이브러리의 유지 관리자의 경우 CoreFX에 없는 기능(오늘날 많은 라이브러리가 있음)은 2가지 버전을 유지해야 하므로 많은 '재미'가 있습니다. #ifdevs가 2~3개가 아니라 문제가 해결되었지만 대부분이 그렇습니다. API 변경에 소비해야 하는 시간에 대해 클라이언트에게 청구할 수 있기 때문에 아마도 다를 수 있습니다. 많은 사람들이 사용하는 범용 시스템을 만들 때는 다릅니다.

컴팩트 프레임워크 지원이 지침이라면 전체 .net 및 CoreCLR에서 ORM을 지원하는 것은 끔찍한 시간 싱크, 많은 좌절감 및 실제로 많은 이점을 얻지 못할 것입니다. .

(누군가가 "하지만 Linux에서 실행되기 전에 얻을 수 있습니다.": 우리 제품은 수년 동안 Mono에서 실행됩니다. 따라서 아니요, 얻을 수 있는 새로운 기능이 아니라 이미 존재했습니다).

SellMeThis 프레임워크. 아 왜 내가 귀찮게.

하지만 그 이후로 빌드된 모든 것은 기본 클래스에 의존합니다.

_cough_ Linq-to-SQL DataContext _cough_

실제로 많은 비 MS ORM을 수행하므로 문제가 발생합니다. dapper를 위해 우리는 단지 비트
글머리 기호 및 DbConnection으로 마이그레이션되었습니다. 우리에게 다시 시간이 있다면, 나는
MS는 무언가를 사용하지 않을 때 [Obsolete]를 사용하도록 강력히 제안합니다. 하지만:
우리는 과거를 바꿀 수 없습니다.

해결하는 것은 매우 고통스러운 문제입니다. 특히 대부분의 경우
라이브러리 작성자는 두 API를 계속 사용해야 합니다.
net40 등, DNX의 다른 방법). 이전에 엄청난 혼란을 게시했습니다
그 dapper는 이것을 하기 위해 사용합니다: 그것은 아름답지 않고, 그렇게 간단하지도 않습니다

만약.

2015년 11월 27일 20:07에 "Natan Vivo" [email protected]이 다음과 같이 썼습니다.

이 논의에서 고려해야 할 한 가지 중요한 사실은 IDb*
인터페이스는 10년 전에 .NET 2.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분에 "Jonas Gauffin" [email protected]이 다음과 같이 썼습니다.

비동기 메서드를
인터페이스를 사용한 결과. _new_ 인터페이스를 만들 수 있었습니다.
비동기 메서드. IAsyncDbCommand, IAsyncDataReader 등. 그러면 다음을 수행할 수 있습니다.
기본 클래스가 두 가지 유형의 인터페이스를 모두 구현하도록 합니다.

ADO.NET 사용자는 비동기 버전 또는 동기 버전을 사용하고 있습니다.
버전이 아니라 둘 다입니다. 그래서 그것은 잘 작동했을 것입니다.

라이브러리 개발자의 경우 기능이 성장하고
인터페이스는 동일하게 유지됩니다. 그게 목적이 아닙니까? 새로운 소개
새로운 기능을 위한 인터페이스. 기본 클래스로 작업하는 것은 고통입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/dotnet/corefx/issues/3480#issuecomment -160201361.

친구들.. 코드를 업데이트하고 메이저 버전을 올려보세요. 완료.

예, 하지만 코어를 대상으로 할 때 컴파일러 지시문으로 해당 인터페이스를 폴리필하지 못할 이유가 없습니다. 일부 pcl 패키지로 그렇게 했습니다.

나는 마이크로소프트가 코어가 완전하지 않다는 것을 반복해야 한다고 생각하지만 여전히 도움이 되지 않는다. 나는 마이크로소프트가 정직하게 일부 인터페이스를 정리할 필요가 있다고 생각한다. 최근에 매우 일관성 없는 인터페이스가 있고 어느 것을 선택해야 할지 모르는 블로그 게시물이 있었습니다. 제 생각에는 두 번째 비동기 인터페이스를 정의하는 것이 형편없다고 생각합니다. 모든게 비동기였으면 좋았을텐데..

더 이상 사용되지 않는 것으로 표시해야 하는 항목이 있는지 확인하기 위해 전체 프레임워크가 완료되면 좋을 것입니다. 그리고 4.6.2로 릴리스되었습니다.

@mgravell +100. 그렇군요 100% 동의합니다.

실제로 얼마나 영향을 받습니까? 여기서 coreclr에 대해 이야기하고 있습니까? .NET 데스크탑은 coreclr이 따라잡을 수 있을 때까지 앞으로 몇 년 동안 살아 있을 것입니다. 정확히 불평하는 사람들을 위해 여기에서 손실을 보상하는 것은 무엇입니까? 많은 사람들은 기본적으로 그것이 세상의 종말이라고 말합니다.

@leppie 실제로, 그것은 몇 년 동안 주변에 있을 것입니다. 그리고 우리는 앞으로 몇 년 동안 우리 코드에서 이러한 핵과 해결 방법을 유지해야 할 것입니다. 여기서 논쟁의 요점은 둘 사이의 공통 다리를 제거하는 것입니다. 해당 작업량은 BCL이 아닌 모든 라이브러리 개발자에게 이전되었습니다. 나는 인터페이스의 장단점을 모두 이해하지만 여기에서 "사소한 것입니다. 계속 진행하십시오"라는 태도를 이해하지 못합니다.

여기에서 직설적으로 말합시다. 라이브러리 소비자가 모두 같은 작업을 수행해야 하는 경우 BCL에 있어야 합니다 . 논쟁은 "그것은 어떤 형태를 취합니까?"입니다.

인터페이스 제거의 장점으로는 현재 실행 중인 새로운 패키징 모델과 함께 _additional_ 버전 관리 메커니즘이 있습니다. X, Y 및 Z에서 사용할 수 있는 클래스는 이제 도구에서 훨씬 더 잘 지원됩니다. 예: 현재 dotnet5.2 대 5.4. 그러나 거기에는 단점도 있습니다. 예를 들어 SqlClient는 여전히 현재와 같이 인터페이스를 구현하는 시점이 아니며(dotnet/runtime#14302 및 dotnet/runtime#15269 참조) @YoungGah가 말한 내용을

그렇다면 5.6(1.5)은 어떻게 될까요? 추상 클래스에 더 많은 구성원이 추가되면 각 데이터 공급자는 움직이는 사람마다 바뀔 수 있는 움직이는 대상에 보조를 맞춰야 합니까? 모든 소비자는 각각에서 사용 가능한 기능에 대한 버전을 결정해야 합니까? 전달되는 클래스의 추상 기반과 일치하도록 앞으로 나아가는 플랫폼의 모든 버전에 대해 어셈블리 버전을 컴파일해야 합니까? 이 모든 것이 추가로 어떻게 작동하는지 100% 명확하지 않습니다. 변경되지 않는 인터페이스가 훨씬 더 명확합니다. 그 위에는 문서가 있습니다. 어떤 버전 _및 플랫폼_에서 사용할 수 있는 기능, 방법 등이 앞으로 나아가는 모든 라이브러리 작성자에게 큰 골칫거리가 될 것입니다. 그 우려는 여기에서 반쯤 관련되어 있지만 작동 중입니다.

지금으로서는 앞으로 2주 안에 업데이트될 날을 초조하게 기다리고 있습니다. 내 두려움은 전체 시간 동안 메시징이 "우리는 X를 수행하는 것은 SQL 및 Entity Framework에서 작동하고 그것으로 충분합니다."라는 메시지가 그랬듯이 이러한 단어를 사용하지 않고도 효과적으로 될 것이라는 것입니다. 나에게 라이브러리 작성자 측의 불만은 몇 달 동안 이러한 측면에서 (코드와 토론 모두에서) 진전이 없었다는 것입니다.

100% 동의합니다.

SqlFu(내 Micro ORM)의 v2(이상)를 설계할 때 확장 메서드를 DbConnection/DbCommand 또는 인터페이스에 연결할 위치를 결정해야 했습니다. 내가 발견 이 와 나는 추상 클래스 가기로 결정했습니다.

따라서 저는 IDataReader 제거의 영향을 받았지만 영향을 받지 않았습니다. 왜냐하면 MS는 어떤 인터페이스가 더 이상 사용되지 않아야 하고 어떤 인터페이스가 사용되지 않아야 하는지를 명확하게 밝히지 않기로 결정했기 때문입니다. 하지만 제 경우에는 인터페이스를 교체하는 것이 어렵지 않습니다.

그러나 전용 인터페이스를 갖는 것의 가치를 보고 MS가 이를 유지/추가하는 것이 그렇게 어렵지 않다고 생각합니다. 그들이 이전 인터페이스가 그렇게 잘 설계되지 않았다고 판단하면 괜찮습니다! 새로운 것을 더 구체적으로 디자인하십시오. 적어도 미래에는 같은 문제를 겪지 않아도 됩니다.

(미국의 추수감사절 주간이므로 Microsofties의 응답은 다음 주에 사무실에 돌아올 때까지 매우 제한적입니다.)

이 스레드에서 좋은 제안/버그를 잃지 않도록 반복하고 싶습니다. 현재 기본 클래스/표면 영역 및/또는 향후 버전에 문제가 있는 경우 새 문제를 제출하십시오. 이 논의는 v1 인터페이스에 대해서만 유지하도록 하십시오.

@NickCraver .NET Framework의 버전 간 호환성과 유사하게 .NET Core 노출 영역 버전 간에는 주요 변경 사항이 없습니다. 예를 들어, 기본 클래스에 추상 멤버를 추가하는 것은 변경이 _하지 않을_ 것입니다.

@davkean 당신은 그런 일이 일어나지 않을

기록을 위해 표면 영역에 별도의 문제가 제출됨을 참조하세요. dotnet/runtime#14302 및 dotnet/runtime#15269(각각 9월 25일 및 10월 2일 Microsoft의 최신 업데이트 포함) - 그 후 여러 번 업데이트 및 활동을 요청했음에도 불구하고. 그것은 2 개월과 2 개의 릴리스가 침묵과 함께 사라졌습니다. 이것은 dotnet/runtime#14302가 이 리포지토리 이 문제 는 이제 막 두 번째 문제가 되었습니다). 우리의 좌절을 이해할 수 있습니까?

나는 우리가 주요 변경 사항을 만들지 않을 것이라고 절대적으로 확신합니다. Data Common 팀은 추상 구성원을 도입하지 않고 변경 사항을 만드는 방법을 찾고 있습니다.

@NickCraver 죄송합니다. 이 문제는 잊 히지 않았습니다.

@niemyjski

dnx는 완전히 새로운 프레임워크/런타임입니다.

dnx 런타임 및 corefx 라이브러리가 허공에서 나타났다고 생각한다면 처음부터 개발하는 데 걸리는 시간을 심각하게 과소평가하고 있는 것입니다. CoreFx 라이브러리가 전체 .NET Framework에서 실행된다는 사실은 그것이 완전히 새로운 것은 아니라는 단서를 제공해야 합니다.

인터페이스가 없으면 컴파일러 지시문으로 처리합니다.

예, 하지만 코어를 대상으로 할 때 컴파일러 지시문으로 해당 인터페이스를 폴리필하지 못할 이유가 없습니다.

이 스레드를 시작하기 전에 주석을 읽는 것이 귀찮다면 a) 이유가 있고 b) 이것이 핵심 BCL 인터페이스에 대해 작동할 수 없는 잘못된 전략이라는 것을 알게 될 것입니다.

@nvivo

이 논의에서 고려해야 할 한 가지 중요한 사실은 기본 클래스가 도입된 10년 전 .NET 2.0에서 IDb* 인터페이스가 ADO.NET용 API로 더 이상 사용되지 않는다는 것입니다.

그런 경우라면 10년 전에 기본 클래스에서 더 이상 사용되지 않는다는 것을 알고 있는 인터페이스를 사용하도록 되돌리라는 문제를 열지 않았을 것입니다. API를 통신하는 방식은 더 이상 사용되지 않으며 존재하는 유일한 목적인 [Obsolete] 속성을 사용하는 것입니다. 널리 알려지지 않았다면 지금 어떤 생각을 하고 있든 비추천되지 않습니다. 대부분의 비 MS .NET ORM이 그것에 의존한다는 사실은 그것의 사용 중단이 제대로 전달되지 않았음을 의미합니다.

이러한 인터페이스에 의존하는 코드가 있는 경우 비동기 메서드와 같은 것을 지원하지 않는 매우 구식 API에 대해 코딩하는 것입니다. 즉, 사람들이 계속 사용하기를 원하면 어쨌든 업데이트해야 함을 의미합니다.

거짓 빨대 - 하나가 다른 하나를 의미하지 않습니다. 우리는 이미 비동기 API에 대한 지원을 추가했으며 아니요, 추가해도 기존 고객 코드 기반이 손상되지 않으며 기존 API를 변경할 필요도 없습니다.

자, 이 모든 것이 깨끗한 시작을 만드는 것은 훌륭하지만 한 가지 질문을 해도 됩니다. 자신의 프레임워크를 지원하기 위해 어떤 타협이 이루어졌습니까? Entity Framework를 실행하는 데 필요했기 때문에 과거의 어떤 공포가 마이그레이션되었습니까?

MicroORM을 사라지게 하는 것은 수치스러운 일입니다. .Net 코드를 어느 정도 성능이 좋게 만듭니다(EF는 몇 행을 로드하는 데 500ms가 허용되지 않는 응용 프로그램에 사용할 수 없는 짐승입니다).

인터페이스 대 기본 클래스의 경우: 재사용할 수 있는 모든 것이 가상인 한 기본 클래스는 훌륭합니다. 예를 들어 WCF에서 가장 짜증나는 디자인 결정 중 하나는 많은 기능을 포함하는 봉인된 클래스를 많이 사용하는 것입니다. XML 메시지가 처리되는 방식을 약간 조정해야 한다고 가정해 보겠습니다(interop 때문에). 하나의 작은 기능을 상속하고 재정의하는 대신 다시 구현해야 합니다. WCF 예제에서는 SOLID의 S를 건너뛰었으므로 일반적으로 프로덕션 품질인지 확인하는 데 필요한 테스트 없이 대규모 인터페이스를 구현해야 합니다.

그래서: 우리가 적응할 수 있는 기본 클래스는 좋은 것입니다.

나는 우리가 주요 변경 사항을 만들지 않을 것이라고 절대적으로 확신합니다. Data Common 팀은 추상 구성원을 도입하지 않고 변경 사항을 만드는 방법을 찾고 있습니다.

@davkean 그것은 보장할 수 없으며 당신도 알고 있습니다. ADO.NET은 일부 확장 지점이 있는 공통 API를 통해 노출되는 다양한 기능을 갖춘 타사 소프트웨어와 통신하기 위한 하위 시스템입니다. 데이터베이스 영역에서도 상황이 변경되며 이러한 변경 사항은 이러한 외부 데이터베이스 서비스를 통신하고 사용하는 데 사용되는 API에 영향을 미칩니다. 게다가: 행동의 변화는 _is_ 또한 주요 변화입니다. 그리고 우리는 지난 몇 년 동안 ADO.NET(예: 오류 처리에 관한)에서도 이러한 것을 보았습니다.

전체 ADO.NET API는 종종 SQL Server에 의해 주도되는 이러한 변경의 부작용으로 가득 차 있습니다. 일반적으로 디자인된 다음 SQL 클라이언트로 이동한 경우는 거의 없지만 그 반대입니다(예: SqlClient에서 무시되는 기본 클래스의 기능이 많지 않은 경우). 거기에 제 3자가 필요로 하는 것들은 API에 포함되지 않았습니다.

간단히 말해서, .NET 1.0이 시작될 때 일반적인 디자인이 있었고(많은 영역에서 심각한 결함이 있는 것으로 판명됨) 그 이후로 변경 사항에 대처하기 위해 왼쪽 및 오른쪽 기능으로 패치된 API입니다. 풍경. 그 중 _대부분_은 여전히 ​​API에 있습니다(전부는 아닐 경우). 이제 Microsoft는 인터페이스 중 하나를 제거합니다.

API의 임의의 부분을 제거하여 얻을 수 있는 것은 절대적으로 _아무것도_ 없습니다. 이를 통해 기능이 추가되지 않습니다(예를 들어 여기에서 다시 푸시하는 대신 시간을 보낼 수 있음). 그러나 해당 API 부분을 활용하는 코드는 작동하지 _않습니다_. 이 모든 치즈 이동의 이면이 '다시 시작'하는 것이라면 반드시 하십시오. 그러나 API를 재설계하여 진정한 범용 API가 되도록 하십시오. 수년 동안 쌓여 있던 _모든_ 덩어리를 제거하십시오. .

하지만 아직 끝나지 않았습니다. 아무도 이유를 궁금해 할 필요가 없습니다. 우리는 모두 그 이유를 알고 있습니다. 또한 MS 내의 팀이 인터페이스 제거로 인해 큰 피해를 입었다면 애초에 제거되지 않았을 것임을 알고 있습니다.

Microsoft가 기본 클래스를 통해 새로운 기능을 추가할 수 있으므로 타사 공급자가 자동으로 기능의 '형식'을 구현할 수 있다면(예: 공급자가 구현하지 않으면 비동기 메서드가 동기화 메서드로 대체되는 Async의 경우) 좋습니다. 제3자 ORM 개발자(많은 개발자가 제3자 (마이크로)ORM 코드를 통해 _귀하의_ API에 액세스)는 단순히 하나의 클래스를 대상으로 할 수 있음을 의미합니다.

그러나 당신이 그렇게 할 것이라는 보장은 없습니다. 예를 들어 Microsoft 내의 누구도 Oracle 또는 PostgreSql이 ADO.NET에 추가되는 특정 기능에 대해 고민한 적이 없습니다. 예를 들어 UDT, 문서 트리, 커서를 통한 여러 결과 집합의 사용과 같이 모든 ADO.NET 공급자는 이러한 기능을 처리하는 고유한 방법을 찾아야 합니다. (언제?) SQL Server가 JSON 문서와 함께 문서 트리 기능을 가져오면 ADO.NET이 이에 대한 새 API로 업데이트됩니까? ADO.NET 공급자의 오류 보고를 통해 과거에 했던 것처럼?

당신은 그런 보장을 할 수 없으며, MS가 미래에 어떤 것도 망가뜨리지 않을 것이라고 여기에서 말하는 것은 현명하지 않습니다. 모든 API에는 결함이 있고 ADO.NET에는 결함이 가득합니다. 어떤 식으로든 언젠가 누군가가 그것들을 '고칠' 것입니다.

요약하자면 인터페이스는 ADO.NET의 일부이며 API의 다른 곳에서 잘못된 부분도 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를 제외한 모든 공급자)는 지원하지 않는 것을 구현할 필요가 없습니다. Async API를 제공하는 ORM의 타사 코드는 ADO.NET의 Async 메서드와 ado.net 공급자가 비동기를 지원하지 않는 경우 아무도 실제로 알 수 없습니다. 음... 느리기 때문에 알겠지만 그건 제쳐두고요.

이제 ADO.NET에 '디자인' 또는 일반 아키텍처가 없음을 보여주는 좋은 예이기도 합니다. 일반 API에서 트랜잭션 저장점을 만드는 _no_ 방법이 있습니다. 거의 _모든_ 데이터베이스가 DbTransaction의 파생 클래스에서 'Save(string)' 메서드를 사용하여 이를 지원하지만. OleDbTransaction을 제외한 모든 것(MS Access가 지원하지 않기 때문에 적어도 제 의심입니다).

쉽지는 않지만 누구도 쉽다고 말하지 않았다. 이 문제는 새로운 것이 아닙니다. OleDB와 ODBC는 수년 동안 이 문제를 처리했으며 JDBC는 해결 방법을 찾았습니다. Microsoft는 이와 같은 문제를 극복하기 위해 바퀴를 다시 발명할 필요가 없습니다. 또한 DB 영역에 고유하지도 않습니다. 예를 들어 모든 비디오 카드는 Direct3D/X를 통해 개발자에게 노출되는 API를 통해 다양한 기능 하위 집합을 지원합니다. 다른 세계에서 디자인이 어떻게 진행되는지는 실제로 흥미롭습니다. API가 디자인되었으며 이를 지원해야 하는 당사자(JDBC 드라이버, OleDB 드라이버 작성자 등)는 이를 구현해야 합니다. 드라이버가 X를 지원하지 않습니까? 드라이버가 X와 호환되지 않습니다. "Oracle은 ADO.NET v10을 지원하지 않습니다." Oracle 내에서 아무도 그것을 읽고 싶어하지 않습니다. 대신 SqlClient가 선두이며 왜건에서 떨어지는 것이 ADO.NET에 추가되고 그게 전부입니다.

ADO.NET에서 그것이 그들이 한 일입니다. 기본적으로 비동기 메서드는 동기화 변형으로 대체됩니다.

아니요, 그렇지 않습니다. 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 인터페이스를 확장하는 것은 불가능합니다. 우리는 모든 주요 RDBMS를 지원하기 위해 모든 ADO.NET 공급자가 외부 API, 즉 핵심 System.Data 인터페이스에서 구현하는 최소 종속성을 노출하는 구현에 구애받지 않는 API를 제공합니다. 비동기 API는 백그라운드에서 지원하는 구체적인 ADO.NET 공급자에서 비동기 API를 활용하는 IDbConnection의 확장 메서드입니다. 내부적으로는 비동기 지원에 관계없이 지원되는 각 ADO.NET 공급자에 대한 구체적인 종속성이 이미 있습니다. 우리가 "그들과의 이전 버전과의 호환성을 옹호할 아무런 의미가 없다"는 귀하의 제안은 경험이 없고 완전히 근거가 없습니다.

이것을 Microsoft 측에게 물어보겠습니다. (cc @davkean @YoungGah): 완벽한 세상이고 아무 일도

후속 조치:
대답이 '예'라면(RTM 이후 시점에 변경 사항이 있을 것입니다), 어떤 종류의 중단을 보게 될까요? 추가, 새로운 방법? 내 공급자에 대한 기본 클래스를 상속하면 사람들이 사용하는 충돌하는 메서드 등을 추가하면 어떻게 됩니까?

대답이 아니오(절대)인 경우: 인터페이스를 다시 추가하지 않는 이유는 무엇입니까?

이 스레드는 _지금 당장_ 논의하는 데 약간 걸려 있습니다. 이 문제는 최대한 빨리 수정해야 하기 때문에 대부분 좋은 일입니다. 여기 있는 모든 라이브러리 작성자는 릴리스가 완료된 후 무언가를 얻는 것이 얼마나 어려운지 알고 있으며 이것이 우리가 그렇게 열심히 노력하는 이유입니다. 불행히도 _미래_ 추가 및 변경에 대한 명확한 계획이 없으면 정보가 부족한 주장이 더 많이 발생합니다.

앞으로의 계획은?

이 경우 추상 클래스를 통해 강제로 구현해서는 안 됩니다. IMO

Microsoft는 .NET 4.5에 대해 중단되는 변경 사항을 적용하지 않습니다. Windows의 일부입니다. 호환성이 왕입니다.

Microsoft는 4.5에 영향을 주지 않는 .NET Core에서 중단되는 변경 작업을 수행할 수 있습니다. 나는 그들이 ADO.NET과 같은 낮은 수준에서 1.0 RTM을 게시할 것인지 의심하지만 그 기준은 더 낮습니다. Windows의 일부가 아니며 .NET Core 버전을 나란히 배포할 수 있습니다.

추상 클래스는 변경할 수 있습니다. 이는 중단되지 않습니다. 기본 구현으로 가상 메서드를 추가하기만 하면 됩니다. ADO.NET 비동기 메서드로 이미 완료되었습니다. .NET Core가 도입되면서 호환성을 유지하려면 .NET 4.5 릴리스와 함께 공유 클래스를 변경해야 한다고 생각합니다. 그것이 잘못되었고 인터페이스에만 적용되는 경우 누군가가 저를 수정합니다.

@FransBouma

공식 공급자는 SqlClient를 제외하고는 ODP.NET과 같은 다른 모든 형식의 비동기 코드를 구현하지 않으므로 호출 코드가 동기화 변형으로 대체됩니다.

당신 말이 맞아요. 하지만 그것은 API의 문제가 아니며 구현자가 더 게으르거나 이해력이 부족합니다. 예를 들어 MySql 커넥터는 TaskCompletionSource를 만들고 동기화 메서드로 완료하여 모든 비동기 메서드를 다시 구현했습니다. 코드 기반의 절반만 삭제하고 동일한 동작을 유지할 수 있습니다.

인터페이스가 그것을 해결할 것이라고 말하지는 않지만 비동기에 대한 기본 동작이 없으면 적어도 일부는 이것을 생각하게 만들 것입니다. 매우 기술적인 사람들의 90%가 비동기 작업을 이해하지 못한다는 사실도 도움이 되지 않습니다.

추상 클래스는 변경할 수 있습니다. 이는 중단되지 않습니다. 기본 구현으로 가상 메서드를 추가하기만 하면 됩니다. ADO.NET 비동기 메서드로 이미 완료되었습니다.

이것은 깨는 것입니다. 이 구현이 추가되었다는 사실을 모르고 사람들이 이 생각을 소비하는 것을 하위 분류한 모든 라이브러리에 문제가 있습니다. 아, 이 구현은 이제 postgresql에서 지원됩니다. BAM ERROR wtf가 발생했습니다...

db 추상화에 대한 강제 구현이 잘못되었습니다.

인터페이스 또는 기본 클래스 여부는 중요하지 않습니다. 주요 변경 사항이 있습니다. 그러나 강제로 미리 정의된 구현은 잘못되었습니다.

다형성은 그런 식으로 작동하지 않습니다. 메서드를 모르면 재정의할 수 없습니다. 참조가 DbConnection이고 QueryAsync를 호출하면 해당 메서드 또는 재정의된 항목만 호출합니다. 서브클래스에 이미 존재하는 QueryAsync라는 메서드는 호출되지 않습니다.

같은 이름으로 숨기는 방법 절을 재정의하는 것을 혼동하고 있습니다.

@JamesNK

메서드가 추상으로 정의된 경우 기본 클래스에 구현이 없습니다. 이것은 하위 클래스에 구현을 추가해야 하기 때문에 타사와의 계약을 위반합니다.

재정의할 수 있도록 메서드를 가상으로 만들면 하위 클래스에 의미가 없을 수 있는 구현이 기본 클래스에 존재합니다. 라이브러리 작성자가 구현하지 않은 구현이 존재하기 때문에 여전히 중단됩니다. 물론 앱이 컴파일될 수 있고 모든 것이 늠름하지만 누군가가 그 메서드를 호출하고 하위 클래스에는 유효하지 않습니다. 그건 틀렸어요. 하위 클래스에 속하지 않는 강제 구현입니다.

따라서 구현이 존재할 수 있는 추상 클래스는 하위 클래스에 속하지 않습니다. 또는 타사에 대한 기본 구현이 없는 인터페이스.

@philip-haydon 그렇기 때문에 추상 메서드가 아닌 가상 메서드로 구현됩니다.

이미 동일한 서명(이름/인수)을 가진 멤버가 있는 하위 클래스만 중단할 항목을 추가할 수 있습니다. 인수가 다르면 개발자가 오버로드를 실수하면 미묘한 버그가 발생할 수 있습니다.

하위 클래스에 속하지 않는 강제 구현입니다.

그런 다음 거기에 두지 마십시오.

@jamesnk

거기에 두지 마세요. 이것이 우리가 인터페이스 제거를 주장하는 이유입니다.

가상으로 만들어도 문제가 해결되지 않습니다. 미리 정의된 구현이 없어야 합니다. 이야기의 끝

@JamesNK 이 경우 우리는 그것을 거기에 두지 않았고, _Microsoft_는 그것을 초록에 포함시켜 거기에 넣었습니다. 상속받은 _모든_ 제공자에서 작동한다고 가정되는 메서드를 추가하는 것은 기술적으로 중단되지 않더라도 효율적으로 원활하게 진행되는 것을 실제로 볼 수 없습니다("신규를 사용해야 함" 컴파일 경고 _기술적으로_ 중단되지 않음). _대부분의_ 경우에 공유 또는 즉시 공유 구현이 없을 것입니다. 그래서 대안은 무엇입니까? 그 가상 안에 throw new NotImplementedException() ? 그것은 처음부터 존재하는 것에 대한 논쟁이 아니며 더 많은 (런타임) 문제가 있습니다.

오늘에서 살펴 보자 : 나는 훨씬 오히려 볼 것 IDbAsyncConnection 추가를 할 때 오히려 혼란과 비효율로 이어지는 내부적으로 동기화 할 수있는 메소드를 사용하여 한 무리의보다 공급자가 지원하는 우리가 오늘이 무슨 이에 초록.

혼란과 비효율을 초래하는 커버 아래에서 동기화되는 여러 메서드보다 공급자가 지원할 때 IDbAsyncConnection이 추가되는 것을 훨씬 더 보고 싶습니다.

@NickCraver +1000. 이 버그처럼 여기 오라클 팀은 단지 수단 비동기 무엇을 이해하지 못합니다.

인터페이스로 그렇게 할 수 있습니다. 문제는 여러 인터페이스를 요구하는 인수를 수락할 수 없다는 것입니다. 예를 들어 IDbAsyncConnection 및 IDbConnection 둘 다인 유형이 필요합니다. 당신은 강력한 타이핑을 잃어버리고 매우 사용자 친화적이지 않다고 생각하는 COM 스타일 인터페이스를 쿼리하기 시작해야 합니다. API 설계에서 제 자리가 있는 도구이지만 기본적으로 사용하게 될지는 모르겠습니다.

기본 구현에서 NotImplementedException이 발생했다면 이를 기본 클래스에 연결하는 것은 잘못된 일입니다. 내가 말했듯이, 거기에 두지 마십시오. 누군가가 하는 것을 보면 문제를 제기하십시오.

어느 쪽이든, 그것이 인터페이스이든 추상 기본 클래스이든, 내 경험은 원래 설계되지 않은 라이브러리에 새로운 기능을 추가하지 않고 세상을 깨뜨리는 일은 매우 어렵습니다.

@JamesNK는 IDbAsyncConnection 여기에서 IDbConnection 상속할 것으로 예상되지만 반드시 그럴 필요는 없습니다. 공통 구성원을 공유하거나 공통 기반에서 상속할 수 있습니다. 예를 들어 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분에 "Shahid Khan" [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년 된 코드베이스와의 하위 호환성이 왕입니다).

내가 생각하는 것:

• 인터페이스를 제거하면 상황이 악화 됩니다.
• [Obsolete]로 장식될 때까지 쓸모없는 것은 없습니다. 그리고 어느 시점에서 누가 무엇을 생각하는지는 중요하지 않습니다. 이것은 계약이며 단순히 만족하지 못한다면 그렇지 않습니다.

내가 원하는 것:

• 기본 클래스가 아닌 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에 대한 결정은 이러한 핵심 추상화가 동등하게 제공되어야 하는 더 넓은 생태계를 고려하여 이루어지지 않는다는 것입니다.

• 인터페이스를 제거하면 상황이 악화됩니다.
• [Obsolete]로 장식될 때까지 쓸모없는 것은 없습니다. 그리고 어느 시점에서 누가 무엇을 생각하는지는 중요하지 않습니다. 이것은 계약이며 단순히 만족하지 못한다면 그렇지 않습니다.

정확하게.

인터페이스 버전 관리와 관련하여. 내가 틀렸다면 정정하지만 CoreClr의 요점은 더 세밀하고 독립적인 버전 관리라고 생각하십니까? 획기적인 변화? 팔! 새로운 메이저 버전이 출시되었습니다.
15년의 디자인 경험 후에 같은 실수를 반복하지만 이제는 독립적으로 버전을 지정하고 너겟 패키지를 릴리스하게 될 것 같습니다. 위의 주장은 더 이상은 아니지만 오래된 모놀리식 프레임워크와 동일합니다.
이전 버전과의 호환성이 필수인 경우 해당 인터페이스를 제거할 수 없습니다. 그렇지 않은 경우에는 이에 대한 이야기를 중단하고 API를 처음부터 설계해 보겠습니다. 이번에는 주요 ORM 작성자 및 기타 ADO.NET 경험이 풍부한 개발자의 의견을 경청합니다.
감사합니다.

@abatishchev 아주 좋은 지적. 나 자신도 궁금했습니다. 이전 버전과의 호환성 주장의 요점은 실제로 무엇입니까? CoreClr에 새로운 기능이 추가되면 그것을 사용하는 모든 것이 .net full에서 실행되지 않으므로 안전을 위해 일반적인 태도만 사용할 수 있습니다. (그것은 결코 잘 작동하지 않았습니다).

긴 침묵에 대해 죄송합니다.

.NET Core로 포팅

먼저 .NET Core에는 우리를 포함하여 많은 사람들이 바라는 것만큼 많은 API가 사용 가능하지 않다는 점에서 방에 있는 코끼리에 대해 이야기해 보겠습니다.

저는 기존 자산을 .NET Core로 이식하는 영역에 접근하는 방법에 대한 일련의 문서를 작성하기 위해 팀과 협력하고 있습니다.

현재 .NET Framework/Mono에만 존재하는 더 많은 기능을 .NET Core로 이식할 계획입니다. 이 문서는 우리가 그것을 어떻게 할 것인지, 어떻게 우선 순위를 매길 것인지, 그리고 어떤 메커니즘이 될 것인지를 설명할 것입니다. 그 작업이 공개적으로 이루어지기를 바랄 뿐만 아니라 커뮤니티가 더 많은 기능을 이식하는 데 도움이 되도록 하고 싶습니다.

주요 변경 사항

사람들이 .NET Core에 대해 이야기할 때 많은 혼란을 일으키는 한 가지 영역이 있습니다. 한 가지 명확히 하겠습니다.

.NET Core에 .NET Framework보다 적은 수의 API가 있는 경우 이는 주요 변경 사항이 아닙니다.

그 이유는 .NET Core가 새로운 플랫폼이고 기술적으로 임의의 API 집합을 가질 수 있기 때문입니다. 그러나 물론, 우리는 임의의 집합을 원하지 않습니다. 그것이 우리가 과거에 했던 것입니다. .NET Core의 목표는 사람들이 .NET Framework 및 .NET Core에서 실행되는 라이브러리(및 콘솔 앱을 사용하여 특정 확장 앱까지)를 작성할 수 있는 스토리를 갖는 것입니다. 이를 위해서는 100% 호환되는 두 플랫폼의 하위 집합이 있어야 합니다. 이러한 맥락에서 우리가 주요 변경 사항에 대해 이야기하는 것을 듣게 될 것입니다.

무엇보다 우리의 의도는 .NET Core 내에서 높은 호환성 표시줄을 갖는 것입니다. 즉, 한 버전의 .NET Core API와 다른 버전 간에 API 주요 변경 사항을 수행할 계획이 없습니다.

인터페이스

인터페이스에 구성원을 추가하는 것은 정의상 주요 변경 사항입니다. 어떤 사람들은 영향이 낮고 이를 모델링할 수 있는 방법이 있다고 주장하지만 현재로서는 바이너리 및 소스 브레이킹 변경입니다.

COM을 기반으로 하므로 인터페이스에 크게 의존하는 WinRT는 IFoo , IFoo2 , IFoo3 와 같은 더 많은 인터페이스를 생성하여 이 문제를 해결합니다. 그것은 가능하지만 견딜 수 있게 만드는 런타임이나 언어 기능이 없으면 확실히 지저분합니다. 지금까지는 그런 기능이 없습니다. 그러나 언어 디자인 팀의 일원으로서 나는 제안을 듣는 데 상당히 관심이 있습니다. 다른 언어와 플랫폼은 그 공간에서 관련 아이디어를 가지고 있으며, 저도 옵션(예: 혼합/특성, Swift의 모든 확장 또는 인터페이스의 기본 멤버)을 적극적으로 찾고 있습니다.

우리는 여전히 이전 버전과의 호환성을 고려하기 때문에 일반적으로 인터페이스보다 추상 기본 유형을 선호합니다.

ADO.NET 인터페이스

이 모든 것을 말하면서 이 스레드의 원래 질문에 대해 이야기해 보겠습니다. ADO.NET 공급자 인터페이스를 노출합니다.

David가 설명했듯이: 우리는 .NET 2/Visual Studio 2005에 있는 추상 기본 유형이 도입되었을 때 이러한 인터페이스가 더 이상 사용되지 않는 것으로 간주했습니다. 이러한 인터페이스를 갖는 것이 ORM 프레임워크를 .NET Core로 이식하는 데 중요하다는 강한 믿음이 있는 것 같습니다. 나에게 이것은 인터페이스를 .NET Core로 이식해야 한다는 충분한 증거를 제공합니다.

그러나 모든 새로운 API와 마찬가지로 구성 요소화된 스택이 있는 .NET Core의 주요 목표 중 하나를 염두에 두어야 합니다. IDataReader 인터페이스는 DataTable 에 대한 종속성이 있으며 DataSet 에 대한 종속성이 있습니다. dotnet/runtime#14302에 설명된 대로 우리는 DataTable 대한 지원을 추가하는 것을 반대하지 않지만 DataSet 레거시를 고려합니다. 그러나 여전히 별도의 패키지로 추가할 수 있지만 어느 쪽이든 인터페이스 -> DataTable -> DataSet 에서 종속성 체인을 끊어야 합니다. @YoungGah 와 그곳 에서 무엇을 할 수 있는지 알아보겠습니다.

이 접근 방식이 문제를 해결할 수 있습니까?

내가 실수하지 않는 한, IDataReader의 유일한 DataTable 종속성은
GetSchemaTable() 메서드, 이미 DataTable에서 자세히 설명
체인. 하지만
나중에 유사한 기능에 대한 _some_ 마음을 추가하기를 희망합니다(
DataTable을 통해 여부)를 통해 이것을 노출하는 것이 매우 어색합니다.
나중에 인터페이스를 확장하는 것이 문제가 되므로 인터페이스. 그렇지 않을거야
"지금은 방법을 제거하고 나중에 다른 것을 추가하십시오"만큼 간단합니다.
2015년 12월 5일 오전 12시 17분에 "Immo Landwerth" [email protected]이 다음과 같이 썼습니다.

긴 침묵에 대해 죄송합니다.
.NET Core로 포팅

먼저 .NET이라는 방의 코끼리에 대해 이야기해 보겠습니다.
Core에는 많은 사람들이 사용할 수 있는 API가 거의 없습니다.
우리는 - 희망합니다.

나는 우리 팀과 협력하여 우리가 어떻게 가고 있는지에 대한 일련의 문서를 작성하고 있습니다.
기존 자산을 .NET Core로 이식하는 영역에 접근합니다.

현재만 제공되는 기능을 더 많이 이식할 계획입니다.
.NET Framework / Mono to .NET Core에 있습니다. 이 문서는
어떻게 할 것인지, 어떻게 우선 순위를 매길 것인지, 메카닉이 무엇을 할 것인지
이다. 나는 그 일이 공개적으로 일어나기를 바랄 뿐만 아니라
커뮤니티를 활성화하여 더 많은 기능을 이식할 수 있습니다.
주요 변경 사항

사람들이 이야기 할 때 많은 혼란을 일으키는 한 분야가 있습니다.
.NET 코어. 한 가지 명확히 하겠습니다.

.NET Core에 .NET보다 API가 적은 경우에는 주요 변경 사항이 아닙니다.
뼈대.

그 이유는 .NET Core가 새로운 플랫폼이고 기술적으로
임의의 API 세트가 있습니다. 그러나 물론 우리는 원하지 않습니다.
임의의 집합
http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
-- 그것이 우리가 과거에 했던 일입니다. .NET Core의 목표는
사람들이 라이브러리(및 콘솔 앱을 사용하여 특정
.NET Framework 및 .NET Core에서 실행될 앱 확장). 이것
100%인 두 플랫폼의 하위 집합이 있어야 합니다.
호환 가능. 이러한 맥락에서 우리가 주요 변경 사항에 대해 이야기하는 것을 듣게 될 것입니다.

무엇보다 우리의 의도는 .NET Core 내에서 높은 호환성 표시줄을 갖는 것입니다.
즉, 우리는 API 브레이킹 체인지를 수행할 계획이 없습니다.
.NET Core API의 한 버전과 다른 버전.
인터페이스

인터페이스에 구성원을 추가하는 것은 정의상 주요 변경 사항입니다.
어떤 사람들은 영향이 낮고 모델링할 수 있는 방법이 있다고 주장합니다.
그러나 오늘날에는 바이너리 및 소스 브레이킹 체인지입니다.

COM을 기반으로 하므로 인터페이스에 크게 의존하는 WinRT는
IFoo, IFoo2,
아이푸3. 할 수 있지만 런타임 없이는 확실히 지저분합니다.
견딜 수 있도록 언어 기능을 제공합니다. 지금까지는 그런 기능이 없습니다.
그러나 언어 디자인 팀의 일원으로서 저는 매우 관심이 많습니다.
제안을 듣습니다. 다른 언어와 플랫폼에는 관련 아이디어가 있습니다.
옵션도 적극적으로 검토하고 있습니다(예:
mix-ins/traits, Swift의 모든 확장 기능 또는 기본 멤버
인터페이스).

우리는 여전히 이전 버전과의 호환성에 신경을 쓰기 때문에 일반적으로 선호합니다.
인터페이스를 통한 추상 기본 유형.
ADO.NET 인터페이스

이 모든 것을 말하면서 이 스레드의 원래 질문에 대해 이야기해 보겠습니다.
ADO.NET 공급자 인터페이스를 노출합니다.

David가 설명했듯이: 우리는 추상 기반이
.NET 2/Visual Studio 2005에 있는 유형이 도입되었습니다.
이러한 인터페이스를 갖는 것이
ORM 프레임워크를 .NET Core로 포트합니다. 나에게 이것은 충분한 증거를 제공한다
인터페이스를 .NET Core로 이식해야 합니다.

그러나 모든 새로운 API와 마찬가지로 다음 중 하나를 염두에 두어야 합니다.
구성 요소화된 스택이 있는 .NET Core의 주요 목표입니다. 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/DataSet API에 의존하는 사용자를 위한 상당한 작업을 생성합니다.

저는 개인적으로 DataTable/DataSet을 죽이는 것이 좋은 일이며 새롭고 더 나은 메타데이터 API가 도입되어야 한다고 생각합니다(DataTable/DataSet을 죽이지 않고도 이것이 사실이라고 생각합니다). 나는 최소화하지 않는다
이 파손으로 인해 ORM(및 기타) 소비자가 겪는 고통이 있지만 한 가지 기억해야 할 점은 정리하고 파손을 소개할 기회가 있다면 .NET Core가 바로 그 기회라는 것입니다.

여기서 또 다른 실망스러운 요소는 ADO.NET 인터페이스를 유지한다는 것은 DataTable/DataSet도 유지한다는 의미입니다. 즉, 개인적으로 인터페이스 문제에 대해 그다지 강하게 느끼지는 않지만 유지한다는 것은 DataTable/DataSet을 유지하는 것을 의미하므로 더 문제가 되는 것 같습니다.

여전히 인터페이스에 의존하는 ORM이 얼마나 많은지 모르고 기본 클래스로 전환하는 데 얼마나 많은 노력이 필요할지 모르기 때문에 선택이 그다지 좋지 않습니다. 여기 클리어. 하지만 내 직감은 누군가가 고통을 겪더라도이 기회를 잡고 정리하는 것입니다. . .

추신 당신이 무엇을 하든지 인터페이스 폭발의 경로를 따라 가지 마십시오, 즉 IFoo2, IFoo3. 그것은 단지 해결책이 아닙니다.
PPS .NET Core에서 새로운 비 DataTable 메타데이터 API를 생성하기로 결정하고 .NET Core 라이브러리를 .NET Framework에서 실행하기로 결정했다면, 이는 새로운 API와 함께 새로운 .NET Framework를 릴리스해야 함을 의미합니다. .NET 코어.

@terrajobst 침묵을 깨주셔서 감사합니다 ;). 핵심 문제는 ADO.NET에 대한 설계가 없다는 것입니다. 꽤 오랜 시간 동안 없었고 API의 다양한 부분에서 몇 분 이상 생각하지 않고 여러 기능을 추가한 것으로 나타납니다. 나는 이것 에 대해 번뿐 이므로 .NET Core는 이전 버전과 호환되어야 한다는 (내 생각에는 어리석은) 규칙에 의해 보류되어서는 안 됩니다. .NET 전체.

즉, 상황이 ADO.NET에 대해 더 나은 방향으로 바뀌지 않을 경우(즉, 일반 API가 설계된 실제 디자인을 얻게 되며 SqlClient에 특화되고 그 반대가 아닙니다! 따라서 사용할 수 없는 기능은 SQL Server이지만 다른 데이터베이스에서는 일반 API에 추가되고 ADO.NET 공급자 작성자에게 남겨지지 않음), 다음으로 가장 좋은 방법은 인터페이스와 타사 개발자 #ifdef를 포함하여 가능한 한 많이 이식하는 것입니다. 남을 구덩이 주변.

그러나 IDataReader 인터페이스는 이식되지 않은 형식에서 .NET 전체 _if_ 데이터 테이블과 역호환성을 유지하기 어렵게 만들기 때문에 DataTable 종속성이 문제가 될 수 있습니다. 그러나 나는 그것이 어쨌든 잃어버린 원인이라고 생각합니다. MS는 .NET 전체가 .NET 코어만큼/빈번한 업데이트를 받지 못할 것이라고 여러 번 말했습니다. 따라서 .NET 코어에 _new_가 추가되면 라이브러리를 사용하므로 아무도 사용할 수 없습니다. .NET 전체와 즉시 호환되지 않습니다. 여기에 뭔가 놓칠 수 있으므로 그런 경우 수정해 주세요. :)

그것만으로도 이상한 상황이 됩니다. 이전 버전과의 호환성이 있어야 하지만 실제로는 달성하기 어렵고 어쨌든 적청어처럼 보입니다. IMHO가 먼저 해결되면 그 결과를 사용하여 .NET core의 API로 수행할 작업에 대한 적절한 결정을 내릴 수 있습니다. 그렇다고 모든 API가 잘못 설계되었다는 것은 아니지만 ADO.NET(이전 게시물에서 설명한 대로)에서는 여러 해 동안 작업이 제대로 수행되지 않았습니다. 완전히 중단하고 대신 더 강력하고(JDBC는 여전히 강력하고 ODBC는 25년 전과 같이 작동함) 변화에 적응할 수 있는 시스템을 구현하는 것이 좋습니다.

이것에 대해 조금 더 생각해보면, 하위 호환성 요구 사항에 대한 @FransBouma 의 의견은 많은 의미가 있습니다. .NET Core의 약속 중 하나는 구성 요소화된 Nuget 패키징 덕분에 더 빠른 반복입니다. 대신 .NET Framework 업데이트는 1년에 1/2회 제공되며 필요할 때마다 .NET Core 업데이트를 릴리스할 수 있습니다. 업데이트가 .NET Framework와의 이전 버전과의 호환성을 결코 깨뜨릴 수 없다면 이것의 가치는 심각하게 제한되는 것 같습니다...?

이전 버전과의 호환성이 이 ADO.NET 관련 논의를 훨씬 뛰어넘는 요구 사항이라는 것을 알고 있습니다.

@roji의 반대입니다 . API를 중단하지 않으면 짧은 반복이 활성화됩니다.

당신이 .Net 개발자이고 기본 프레임워크의 API가 지속적으로 변경되기 때문에 빌드가 매주 계속 중단된다면 다른 플랫폼을 고려하기 시작하는 데 오래 걸리지 않을 것입니다.

따라서 중요하지 않은 변경 사항에 의해 주도되는 빠른 반복입니다.

(편집됨)
예를 들어 클래스 인터페이스, 동작 변경(!) 또는 동작 추가에 무언가를 추가해야 할 때까지 변경을 중단하지 않고 반복할 수 있습니다. 이는 문자 그대로의 주요 변경(동작 변경은 tho임)이 아니지만 .net core는 코드를 .net full과 호환되지 않도록 하므로 .net core가 _해당 코드에 대해 .net full과 더 이상 호환되지 않게 됩니다. .NET 코어로 내려오는 IMHO는 항상 .NET 전체에서와 동일한(클래스) 인터페이스 및 동작을 가지며 마지막 바이트(IMHO는 지속 가능하지 않음) 또는 나중에 백포트되는 새로운 기능(말 그대로 MS는 btw)를 .NET 전체로 변환하여 효과적으로 이전 버전과 호환되지 않도록 했습니다. 그것은 당신이 물론 울타리의 어느쪽에 달려 있는지에 달려 있습니다. '정의 된 동작 B를 가진 (클래스) 인터페이스 X의 공통 세트가 있고 .NET core와 .NET 모두가 이것을 구현하고 X & B가 승리합니다' t change in the future', 그것은 여전히 ​​X & B 외부에 새로운 것을 얻을 수 있는 새로운 프레임워크가 있다는 것을 의미할 것이며, 정확히 그곳에 상황이 바뀔 수 있고 미래가 있는 곳이 있습니다.

예를 들어 .net 코어의 X & B에서 사용되는 인터페이스/클래스는 실제로 .NET 코어의 새 클래스/인터페이스를 둘러싼 래퍼입니다. 그런 다음 X & B 또는 .NET 전체와 공통된 API 없이 더 나은 디자인으로 새로운 것을 사용하는 것은 개발자에게 달려 있습니다.

우리는 이미 X & B에서 누락된 부분을 해결하는 방법을 #ifdef해야 하므로 두 프레임워크를 모두 지원할 때 IMHO는 조만간 동작이 변경될 때 .NET Core의 새 인터페이스/클래스를 대상으로 지정할 수 있는 것이 좋습니다(심지어 매우 미묘할 수도 있습니다. , 주어진 상황의 다른 예외와 같이) 어쨌든 거기에서 잘리므로 _new_ API(X&B 아님)를 사용하여 .NET Core로 코드를 '포팅'하는 것이 더 좋습니다. 어쨌든 우리는 이식해야 합니다. 적어도 제가 보기에는 그렇습니다.

@ryanbnl ,

@roji 는 프레임워크 및 코어 모두와 호환되고 자체 케이던스에서 실행될 수 있는 프레임워크 패키지(예: GAC가 아님)의 새로운 외부가 아닌 한; 그러나 ORM 제공자에게는 더 많은 변경 사항이 있을 수 있으며 System.Data.IDbConnection 라는 이름은 이미 사용 중입니다...

@benaadams 유효한 의견입니다 - ADO.NET과 같은 비 Nuget 프레임워크 API만 염두에 두었습니다. 그러나 이것들은 문제가 될 만큼 충분한 API 공간을 포함하는 것으로 보입니다.

IDbConnection과 관련하여 무슨 말씀이신지 모르겠습니다만...

@roji 는 예를 들어 System.Data.Database 와 같이 이러한 유형을 제공하는 새 패키지를 의미했습니다. 코어 및 전체와 호환되도록 유지하려면 전체 프레임워크에서 GAC가 될 유형을 재정의할 수 없거나 충돌할 수 있습니다.

너겟 포인트에서; 이것이 전체 및 코어 모두에 대해 너겟에서 살 수 없는 이유가 있습니다. 현재 System.Data API 게시물 4.6.1+를 더 이상 사용하지 않습니까?

그것은 지금 더 큰 고통을 야기할 것입니다. 그러나 일부 호환성은 이미 손상되어 인터페이스를 삭제하거나 DataSet 만 삭제하므로 ORM 공급자가 coreclr에 대해 일부 재작업을 이미 수행해야 합니다.

nuget 및 GAC 프레임워크 외부에 있는 완전히 새로운 API는 netstandard1.2( 예: 4.5.2+, coreclr, UWP, mono/Xamarin 등)와 함께 사용하기 위해 이전 버전과 호환될 수 있습니다. 아마도 나중보다 더 나은 시간일 것입니다.

새로운 API가 achema 등에 대해 작동하고 있음을 감안할 때 DataSet 를 나타내는 것은 오지 않을 것입니다(또는 DataTable ), 이것을 닫아야 합니까? 기본 클래스가 dotnet/corefx#5609 및 유형 전달의 주석을 기반으로 하는 방법인 것처럼 들립니다. 즉, 인터페이스에는 GetSchemaTable() 주어지면 아무 소용이 없고 다른 일부는 호환성을 위해 가져오지 않습니다. ...그게 말이 되나요?

무엇을 닫아야합니까? DataTable/DataSet 종속성 때문에 GetSchemaTable() 가질 수 없는 경우 한 가지이지만 인터페이스는 여전히 복원되어야 하며(필요한 경우 GetSchema 제외) 깊은 종속성이 있는 기존 코드 기반을 쉽게 이식해야 합니다. 누락된 인터페이스는 차단기입니다. dnx/core를 지원하기 위한 작업을 시작하기 전에 인터페이스와 함께 릴리스를 기다리고 있습니다.

나는 @mythz에 동의합니다. 인터페이스는 또 다른 주제이며 매우 중요합니다. 대부분의 사용자에게는 그렇지 않을 수도 있지만 이 동일한 사용자는 소규모 그룹에서 작성한 코드를 사용하고 해당 코드는 이러한 인터페이스(및 DbProviderFactory와 같은 기타 중요한 누락된 ADO.NET 기능)에 의존합니다.

솔직히 말해서 'RTM' 레이블에 대한 극단적인 압박으로 1.0에서 견고한 API를 얻을 수 있을 것이라는 희망은 거의 없습니다. 그것은 다시 .NET 2.0과 같을 것입니다. 첫 번째 버전에서 만든 모든 실수는 수정될 것입니다.

@FransBouma

.NET Core에 인터페이스를 추가하면 추가 변경 사항이 됩니다. 따라서 V1에 대한 컷을 만들지 못하더라도 1.1을 포함한 모든 버전에 추가될 수 있습니다.

그러면 첫 번째 버전에서 만든 모든 실수가 수정됩니다.

문제는 없지만 소프트웨어가 작동하는 방식입니다.

@terrajobst

따라서 V1에 대한 컷을 만들지 못하더라도 1.1을 포함한 모든 버전에 추가될 수 있습니다.

네, 기술적으로 불가능하다는 것이 아니라 그렇게 하는 것(또는 그렇게 하지 않는 것)의 결과가 (광범위한) 결과를 가져오며, 그 결과 Microsoft가 고통받는 사람이 아니라 바로 우리입니다. 지금까지 나는 그것에 대해 약간의 무관심을 보았습니다. 새로운 프레임워크에서 작업하는 것은 모두 멋지고 신나는 일이지만 새로운 청중을 위한 클린룸에서 개발되지 않았습니다. 반대로 배울 역사가 없는 것도 아닙니다.

문제는 없지만 소프트웨어가 작동하는 방식입니다.

보라, 이것은 내가 위에서 의미하는 바이다: 당신은 당신의 결정의 결과를 다루어야 하는 사람이 아니다, 나는 해야 한다. 그리고 나는 이미 당신의 전임자들이 비슷한 결정의 결과를 다루었기 때문에 당신이 같은 실수를 하지 않도록 주의를 주었습니다.

저는 소프트웨어가 어떻게 작동하는지 알고 있습니다. 저는 이제 21년 넘게 전문 소프트웨어 개발자로 일해 왔습니다. 나는 초보자가 아니라 이 특정 분야에서 단련된 전문가로서 솔직한 조언을 했습니다. 당신은 그것으로 당신이 원하는 것을 할 수 있습니다. 나는 당신이 여기에서 가볍게 결정을 내리기 전에 두 번 생각하기를 바랍니다. 그 결과는 매우 광범위하고 제가 말했듯이: 우리는 당신이 아니라 이것들을 다루어야 합니다.

실수라도 나중에 고칠 수는 있지만 아직 하지 않은 일이니 애초에 하지 않는 것이 좋지 않을까요?

당신들은 과민 반응하고 있습니다. 나는 이것의 효과가 이전 .NET과 같은 결과를 가져올 것이라고 의심합니다.

각 응용 프로그램에 coreclr이 번들로 제공되면 레거시가 매우 다른 의미를 갖습니다. asp.net mvc 5의 기능이 mvc 4 또는 3으로 백포트되지 않은 경우 아무도 신경 쓰지 않습니다. 여기에서 레거시라는 것은 다른 의미를 가질 것이며 다른 프로젝트에서 이를 보여주는 역사가 있습니다.

좋은 점은 @terrajobst 가 다음 버전을 위해 이를 고려하기 위해 열려 있습니다.

@nvivo 부디 처리해야 하는 결과를 _I_ 처리하려고 하지 마십시오. 당신이 처리할 필요가 없기 때문입니다. 하지만 저는 처리합니다.

저를 제 자리에 앉혀주신 @FransBouma 에게 감사드립니다. 내가 그 문제에 대해 논평할 수 있다고 생각한 것은 내 실수였다. 당신은 확실히 어떤 종류의 것들이 내 작업에 영향을 미치는지 나보다 더 자격이 있습니다.

사실 제가 이슈를 오픈했는데도 제 업무나 제가 신경쓰는 일에는 전혀 영향이 없습니다. 나는 지구상에서 모든 노력을 기울이는 당신과 같은 가난한 개발자에 대해 생각하고있었습니다.

나는 당신과 같은 사람들이 어려운 문제를 처리하기 위해 여기에 와서 정말 기쁩니다. _당신이_ 처리해야 하는 얼마나 더 중요한 문제가 얼마나 더 중요한 문제인지 주저하지 말고 계속해서 저희에게 말씀해 주십시오.

@FransBouma 감사합니다.

_한숨_ 그런 말을 다 어디서 해요? 내가 하는 말은 '과민 반응을 하고 있어'로 그렇게 하는 것처럼 제발 일을 경시하지 말라는 것뿐입니다. 제가 과민 반응을 하고 있다고 생각하지 않습니다. '당신은 그들을 다룰 필요가 없습니다'라는 말은 _me_에 대한 결과를 의미합니다. 나는 그것들이 무엇인지 알기 때문에 내가 한 것처럼 반응합니다. '과민반응'인 것 같다.

그러나 무엇이든.

여기 와 여기 에 이 문제에 대한 답변이

공식 답변은 다음과 같습니다. 인터페이스는 .NET Core 1.0에 없을 것이며 가능성은 적지만 .NET에 존재하는 것과 다른 형태로 향후 릴리스에 고려될 수 있습니다.

원래 질문이 해결되었으므로 이 문제를 닫습니다.

@nvivo 감사합니다. 하지만 문제가 해결되었다고 결정한 후 문제를 스스로 종료할 수 있는 프로젝트를 실제로 책임지고 있는 사람들에게 공식 답변을 남겨두는 것이 가장 좋습니다.

@terrajobst 인터페이스에 대한 업데이트된 공식 응답/타임라인이 있습니까? 앞으로 이 작업 항목을 추적하는 가장 좋은 방법은 무엇입니까? 새 문제를 열어야 합니까, 아니면 여기에서 계속 업데이트를 제공하시겠습니까?

지금은 이것을 열어 두도록 합시다. 내가 보기에 대답은 "인터페이스를 노출하지 말자"가 아니었습니다. 대답은 "노출 방법을 찾자. 그러나 DataTable 종속성에 대한 의미에 대해 생각해 봅시다."였습니다.

여러분께 너무 늦게 돌아와서 죄송합니다. 팀 내에서 다양한 옵션을 논의한 후 빈 클래스의 DataTable이 있는 인터페이스를 다시 가져오기로 결정했습니다. 이상적인 솔루션은 아니지만 RTM의 시간 프레임을 감안할 때 이 접근 방식을 사용하면 미래에 DataTable/DataSet에 대해 실행 가능한 옵션을 추구할 수 있습니다. v1 RTM에서 System.Data.Common에 대한 인터페이스를 가져오려고 합니다. SqlClient는 v1에 의해 인터페이스를 구현하지 않습니다. 피드백과 인내심에 감사드립니다. 피드백은 데이터 스택을 실행 가능한 제품으로 만드는 핵심 부분입니다.

업데이트를 위해 @YoungGah thx, DataTable 클래스가 빈 자리 표시자가 될 경우 SqlClient v1에서 구현하는 데 그렇게 많은 시간/노력(즉, 보류)이 필요한 이유는 무엇입니까?

@mythz 비용은 기본 유형에서 인터페이스를 구현하거나 기존 메소드로 전달하는 데 있습니다. 비용은 최소화해야 하지만 일반적으로 상황이 나타납니다.

System.Data.Common의 .Net CoreFX에 다음 인터페이스를 추가했습니다.

IData매개변수
IDataParameterCollection
IDataReader
IDataRecord
IDb명령
IDb연결
IDbData매개변수
IDb트랜잭션

이것은 PR https://github.com/dotnet/corefx/pull/6359 에서 수행되었습니다.

@saurabh500 좋은 일이네요 , thx!

:+1:

:+1:

엄청난; 이것이 너겟에 도달하기 위한 이정표가 있습니까? rc3?

2016년 2월 25일 02:54 Saurabh Singh [email protected]
썼다:

System.Data.Common의 .Net CoreFX에 다음 인터페이스를 추가했습니다.

IData매개변수
IDataParameterCollection
IDataReader
IDataRecord
IDb명령
IDb연결
IDbData매개변수
IDb트랜잭션

이것은 PR dotnet/corefx#6359 https://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 메서드가 기본 클래스에 _not_ 있어야 한다고 강력하게 믿습니다. 이는 실제로 나쁘고 낭비입니다. 거기에 다른 제안이 있다면 그렇게 하십시오. 그러나 다시: 그것은 어쨌든 다른 문제가 되어야 합니다.

좋아, 어쩌면 내가 여기에서 나를 잘못 표현했거나 내 말에 너무 강했습니다.

필요한 경우 비동기를 위한 추가 인터페이스를 선호합니다. 내가 괜찮지 않은 것은 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에 의존합니다.

비동기 메서드는 .NET Core에 포함되지 않은 경우 많은 사람들이 비명을 지르기에 충분한 시간 동안 이미 ADO.NET의 일부입니다. ADO.NET에서 비동기 메서드를 사용하는 _레거시 코드_가 있습니다.

나는 그것들이 ADO.NET의 _이미_ 일부이기 때문에 이것이 새로운 인터페이스 API에도 존재해야 한다고 주장합니다.

사람들이 비동기 API를 사용하기를 원하고 사용해야 한다면 이미 할 수 있습니다.
기본 유형을 사용하여 _이 변경 전에_. 결국 요청은
인터페이스를 지원하는 것은 이전 버전과의 호환성을 위해 만들어졌습니다.
인터페이스에 메소드를 추가하면 _완전히 이 문제가 해결됩니다_.
즉, 실제로는 _확장 방법_으로 거의 가능합니다.
추상 기본 유형에 대한 유형 검사, 하지만... 꽤 추하고 그렇지 않습니다.
고통 IMO의 가치.

그래서; 짧은 버전: 개인적으로 async를 추가할 수 없습니다.
인터페이스는 우리가 처음에 원했던 것을 파괴하기 때문에
장소. 비동기를 원하면 기본 클래스에 대해 코딩하거나 다음을 사용해야 합니다.
이러한 세부 사항을 설명하는 도구입니다.

나는 그들이 이미 ADO.NET의 일부이기 때문에 이것이 새로운 인터페이스 API에도 있어야 한다고 주장합니다.

기존 코드와의 호환성을 유지하기 위한 이러한 ADO.NET 인터페이스의 목적을 완전히 오해하고 있습니다. 이것은 _new_ 인터페이스가 아니라 _existing_ 인터페이스입니다. 최신 API에 액세스하려면 구체적인 기본 유형을 참조하십시오.

@nvivo 죄송합니다. 저는 당신을 *Async 메소드가 모두 있습니다. 누락된 특정 항목이 있습니까? 인터페이스에 번들로 포함되어야 한다고 주장하고 있는 것 같습니다. 물론입니다. 하지만 그건 또 다른 문제이므로 열어 보길 권합니다.

현재 접근 방식(동기화보다 비동기화)이 작동하도록 하는 데 필요한 기본 구현이 전체 접근 방식이 작동하도록 하는 끔찍한 절충안이기 때문에 처음부터 인터페이스였으면 합니다. 그러나 우리는 또한 그것을 두 가지 방법으로 가질 수 없습니다. 인터페이스로 이동하거나 중단을 최소화하기 위해 존재합니다(현재의 경우와 같이).

예, 여기에서 우리가 원을 그리며 가고 있다고 생각합니다. 이전에 언급했지만 코드 이식을 돕기 위해 인터페이스를 _just_ 추가해서는 안 된다고 생각합니다. 호환성 관점에서 기본 클래스는 2005년부터 ADO.NET의 공식 API였으며 공급자가 구현하는 것입니다. IDbCommand 또는 IDbConnection을 사용하는 모든 것은 검색/바꾸기와 함께 기본 클래스를 사용하도록 쉽게 이식될 수 있고(이전에 이식되어야 함) 단점이 없습니다.

나는 당신이 ifdef의 팬이 아니라는 것을 알고 있지만, 새로운 플랫폼에 대해 이것을 지원하는 것은 어쨌든 마이그레이션의 일부일 뿐입니다.

나는 이것이 항상 인터페이스여야 한다는 데 동의하지만 그렇지 않았기 때문에 이 문제가 반복되지 않기를 바랍니다. 인터페이스가 추가된다면 적어도 10년 전의 API가 아니라 현재의 API를 나타내야 합니다. 비동기 메서드는 현재 API의 필수적인 부분이며 Microsoft가 꽤 오랜 시간 동안 움직이고 있는 방향입니다. 그것은 여전히 ​​소스 호환이 가능하며 더 완벽합니다.

@mgravell

사람들이 비동기 API를 사용하기를 원하고 사용해야 하는 경우 기본 유형을 사용하여 _이 변경 이전에_ 이미 그렇게 할 수 있습니다.

이것은 아무 것도 할 수 없다는 것이 아닙니다. 그것은 건축에 관한 것입니다. 인터페이스는 계약이며 .NET Core는 이 계약을 API의 재설계된 버전에 추가하는 새로운 프레임워크입니다.

.NET Core는 정말 오래된 코드를 마이그레이션하는 데 도움을 주기 위해 새 API에 공식 계약을 추가해서는 안 되며, 다른 대부분은 어쨌든 누락됩니다. 그것이 우려되는 경우 사람들은 어쨌든 코드를 변경해야 하는 이유를 충분히 찾지 않습니다.

그것이 팀이 하고 있는 전부라면, 그것보다는 OK.. 그것은 단지 나쁜 선택 IMO입니다.

IDbCommand 또는 IDbConnection을 사용하는 모든 것은 검색/바꾸기와 함께 기본 클래스를 사용하도록 쉽게 이식될 수 있고(이전에 이식되어야 함) 단점이 없습니다.

거짓. 이 문제는 이에 영향을 받은 직접적인 경험을 가진 여러 라이브러리 작성자가 이 스레드에서 여러 번 논의했습니다.

나는 당신이 ifdef의 팬이 아니라는 것을 알고 있습니다.

최종 고객이 ifdef를 사용해야 하는 모든 솔루션은 개발 경험이 부족하고 시작이 아닌 것입니다. 즉, 대안이 있을 때 고객이 코드를 #defs로 어지럽히도록 요구하는 성공적인 제품은 결코 없을 것입니다.

인터페이스가 추가되는 경우 최소한 현재 API를 나타내야 합니다.

이것은 새로운 인터페이스가 아니라 복원된 인터페이스입니다. 현재 및 미래 API는 이러한 인터페이스가 아니라 기본 클래스입니다. 여기에는 문제가 없어야 합니다. 이러한 인터페이스가 있다는 사실을 잊고 이러한 인터페이스가 복원되기 전과 마찬가지로 기본 유형을 계속 사용할 수 있습니다.

더 이상 이 스레드에 추가되는 새 값이 없습니다. 기존 ADO.NET 인터페이스가 복원되어 이 스레드를 중단할 수 있습니다. 이 스레드에서 필요한 것은 기존 인터페이스와 관련된 DataTable 및 GetSchemaTable() 대한 업데이트뿐입니다. 아키텍처 변경을 제안하거나 새 인터페이스를 옹호하려면 이 목록에 있는 모든 사람이 스팸을 받지 않도록 하는 새 문제를 엽니다.

@mythz 동의하지 않는 데 동의합시다.

다른 ORM 개발자로 내 2센트를 추가하는 것만으로도 인터페이스가 지원하지 않는 추상 클래스는 항상 코드 냄새가 납니다. 최소 요구 사항 인터페이스 API로 오버로드된 추상 클래스 및 메서드 서명과 일치하도록 제공되는 새 인터페이스를 보고 싶습니다.

발언에 대해 커뮤니티에 엄지손가락을 치켜듭니다.

추상 클래스는 인터페이스가 지원하지 않을 때 항상 코드 냄새입니다.

@psibernetic 그 진술을 이해하는 데 도움을 줄 수 있습니까? 코드 냄새는 어떻습니까?

@psibernetic

인터페이스와 추상 클래스는 우리에게 계약을 제공하고, 둘 다 API에 대한 추상화와 좋은 정의를 제공합니다. 인터페이스는 둘 이상의 인터페이스를 구현할 수 있거나 다른 기본 클래스의 하위 클래스인 클래스를 구현할 때 가장 유용합니다(이것이 기본 클래스의 매우 큰 장점이라고 가정). 이 경우 특히 특정 공급자에 대한 Connection, Command 등의 구체적인 클래스는 추상 API 정의와 강력한 IS A 관계를 갖습니다. 일부 개발자가 하위 클래스에 IDbConnection 또는 IConnection에 대한 구체적인 구현을 추가해야 하는 시나리오를 상상할 수 없습니다. 거의 유일한 시나리오는 추상 클래스에 대해서만 파생되는 새 클래스가 될 것이며 인터페이스에서 동일한 정의를 "복제"하는 것은 API 디자이너에게 더 많은 작업(불필요한)입니다.

두 개의 동일한 추상화를 갖는 구체적이고 구체적인 이점이나 시나리오가 있습니까? 인터페이스가 이 특정 API 디자인에서 추상 클래스에 비해 실용적이고 실질적인 이점을 제공할 때?

인터페이스에 대해 생각할 수 있는 유일한 이점은 이러한 인터페이스에 의존하는 실제 실행 코드를 덜 중단하기 위해 이전 인터페이스와 필요한 이전 버전과의 호환성입니다. 이전 인터페이스가 없었다면 추상 클래스로 충분할 것이라고 확신합니다.

@eocampo 추상 클래스가 아마도 "충분히 좋은" 추상화 및 계약을 제공한다는 말이 맞습니다. 저는 항상 IAsyncCommand 등과 같이 수행할 수 있는 작업을 나타내는 매우 좁은 인터페이스를 제공하려고 노력합니다. 이렇게 하면 끔찍한 NotSupportedExceptions 또는 NotImplementedExceptions의 가능성이 적은 프레임워크의 디자인 타임에 고려되지 않았을 수 있는 방식으로 내 프레임워크를 연결할 수 있습니다.

@davkean 코드 냄새는 전부는 아니지만 대부분의 경우 구현자가 관련이 없을 수 있는 전체 기본 기능 세트를 구현하거나 상속하도록 요구한다는 것입니다. 캐시나 메모리에서 대신 읽는 IDataReader 구현을 본 기억이 있습니다. DbDataReader 추상 클래스가 이를 허용하는지 확실하지 않지만 이름은 아니오를 의미합니다.

dot net에서 주로 따르는 모범 사례 모델은 인터페이스를 노출하고 기본 클래스에서 상속하지 않습니까?

dot net에서 주로 따르는 모범 사례 모델은 인터페이스를 노출하고 기본 클래스에서 상속하지 않습니까?

@psibernetic 항상 그런 것은 아닙니다. 예를 들어 MSDN 사이트의 이 권장 사항 은 10년이 넘었습니다. 그리고 그 지침은 적어도 .Net Framework 2.0에서 매우 일반적입니다.

또한 이것은 초기부터 .Net의 라이브러리 디자인 지침에 대한 좋은 참조입니다.

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

어쨌든 나는 여기에서 어려운 토론이 지금 두 가지 주제에 관한 것이라고 생각합니다.

a) 인터페이스는 이전 버전과의 호환성을 위한 것일 뿐이며 더 깨끗한 인터페이스와 API 디자인을 허용하기 위해 "처음부터 시작"(코드 깨기)할 수 있습니다.
b) 전체 .Net 프레임워크와 호환되지 않는 비용으로 현대적이고 깨끗한 디자인을 위해 얼마나 갈 수 있습니까? (특히 데이터 액세스에 대한 .Net Core와 Full core 간의 호환성[가장 낮은 수준 및 필수 호환성 아님])

내 관점에서 추상 기본 클래스가 기본 및 기본 계약으로 있는 경우 _interfaces_는 호환성을 위해 이전 것과 일치해야 합니다. @nvivo는 이미 .Net 2.0 이후 공식 계약이 추상 기본 클래스라고 명시했기 때문에 인터페이스가 호환성 문제를 해결하지 못할 것이라고 생각하지만 @mythz 와 @mikeobrien 은 여기에 공급자의 종속성에 대한 하드 데이터도 제공했습니다 1.1 인터페이스에서.

스팸을 중지하고 여기에서 주제에 대해 논의하려면 이 긴 대화를 다시 읽어야 합니다. 우리가 다루고 있는 특정 주제의 목록에 동의할 수 있는지 또는 두세 개의 새로운 주제를 만드는 것이 좋은 아이디어인지 모르겠습니다. 각 특정 주제에 대한 문제. 나는 여기에 좋은 점이 많기 때문에 첫 번째 제안에 더 가깝습니다. 나는 우리가 이 모든 것을 다시 요약하고 약간의 잡음(내 것조차도)을 제거하는 방법에 대한 좋은 아이디어가 없습니다.

인터페이스에 대해 말하자면, 마침내 System.Data의 일부를 일반화할 계획이 있습니까? System.Data가 .NET 1.1 이상으로 API를 업데이트하지 않았기 때문에 사람들이 IEnumerable을 얻기 위해 .AsEnumerable() 확장 메서드와 같은 해킹을 사용해야 한다는 점이 항상 저를 괴롭혔습니다.데이터 테이블에서. 프레임워크의 다른 모든 것이 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 및 미래의 모든 공유 인터페이스에 볼트를 고정할 수 있다고 이해합니다. 바이너리 호환성, 제3자 제공자가 모든 것을 구현하도록 강요하지 않습니다. 이것은 쉬운 조롱 가능성을 유지하면서.

이것이 올바른 이해입니까? 그렇다면 이 기능이 .NET에 실제로 적용될 가능성이 있습니까?