Zásadní změny

Pro knihovnu .NET je důležité najít rovnováhu mezi stabilitou stávajících uživatelů a inovací pro budoucnost. Autoři knihoven mají sklon k refaktoringu a přepracování kódu, dokud není dokonalý, ale narušení kompatibility pro stávající uživatele má negativní dopad, zejména u knihoven nízké úrovně.

Typy projektů a zásadní změny

Způsob, jakým komunita .NET používá knihovnu, mění vliv zásadních změn na vývojáře koncových uživatelů.

  • Knihovny nízké a střední úrovně , jako je serializátor, analyzátor HTML, mapovač relačních databázových objektů nebo webová architektura, jsou nejvíce ovlivněné zásadními změnami.

    Balíčky stavebních bloků používají koncoví uživatelé-vývojáři k vytváření aplikací a další knihovny je používají jako závislosti v rámci NuGet. Například vytváříte aplikaci a k volání webové služby používáte opensourcového klienta. Zásadní aktualizace závislosti, kterou klient používá, není něco, co můžete opravit. Je to opensourcový klient, který je potřeba změnit a nemáte nad ním žádnou kontrolu. Musíte najít kompatibilní verze knihoven nebo odeslat opravu do klientské knihovny a počkat na novou verzi. Nejhorší situace je, když chcete použít dvě knihovny, které závisí na vzájemně nekompatibilních verzích třetí knihovny.

  • Knihovny vysoké úrovně , jako je sada ovládacích prvků uživatelského rozhraní, jsou méně citlivé na zásadní změny.

    Na knihovny vysoké úrovně se přímo odkazuje v aplikaci koncového uživatele. Pokud dojde k zásadním změnám, vývojář se může rozhodnout aktualizovat na nejnovější verzi nebo může upravit aplikaci tak, aby fungovala se změnou způsobující chybu.

✔️ Zamyslete se nad tím, jak se vaše knihovna bude používat. Jaký vliv budou mít zásadní změny na aplikace a knihovny, které je používají?

✔️ Minimalizujte zásadní změny při vývoji knihovny .NET nízké úrovně.

✔️ ZVAŽTE vydání významného přepracování knihovny jako nového balíčku NuGet.

Typy zásadních změn

Zlomové změny spadají do různých kategorií a nemají stejný dopad.

Změna způsobující chybu zdroje

Změna způsobující chybu zdroje nemá vliv na provádění programu, ale při příštím překompilování aplikace způsobí chyby kompilace. Například nové přetížení může vytvořit nejednoznačnost ve volání metod, která byla dříve jednoznačná, nebo pojmenování parametrů může narušit volající, kteří spoléhají na pojmenované parametry.

public class Task
{
    // Adding a type called Task could conflict with System.Threading.Tasks.Task at compilation
}

Vzhledem k tomu, že změna zdroje způsobující chybu je problémová pouze v případě, že vývojáři překompilují své aplikace, jedná se o nejméně rušivou zásadní změnu. Vývojáři můžou snadno opravit svůj vlastní poškozený zdrojový kód.

Změna narušující chování

Změny chování jsou nejběžnějším typem zásadní změny: téměř jakákoli změna chování může způsobit logickou chybu u uživatele. Změny v knihovně, jako jsou podpisy metod, výjimky vyvolané nebo formáty vstupních nebo výstupních dat, můžou negativně ovlivnit uživatele knihovny. I oprava chyby se může kvalifikovat jako změna způsobující chybu, pokud se uživatelé spoléhali na dříve poškozené chování.

Přidání funkcí a zlepšení špatného chování je dobrá věc, ale bez opatrnosti může být pro stávající uživatele velmi obtížné upgradovat. Jedním z přístupů, jak vývojářům pomoct řešit změny narušující chování, je skrýt je za nastaveními. Nastavení umožňují vývojářům aktualizovat na nejnovější verzi vaší knihovny a zároveň se rozhodnout, zda zvolí nebo nezvolí kompatibilní změny. Díky této strategii můžou vývojáři zůstat v aktualizovaném stavu a nechat jejich náročný kód se v průběhu času přizpůsobovat.

Například ASP.NET Core MVC má koncept verze kompatibility , která upravuje povolené a zakázané MvcOptionsfunkce .

✔️ ZVAŽTE nechat nové funkce ve výchozím nastavení vypnuté, pokud ovlivní stávající uživatele, a umožněte vývojářům, aby se k funkci přihlásili prostřednictvím nastavení.

Další informace o změnách v chování v rozhraních .NET API naleznete v části Kompatibilita změn v chování .NET.

Binární změna narušující kompatibilitu

Při změně veřejného rozhraní API knihovny dojde k binární zásadní změně, takže sestavení zkompilovaná ve starších verzích knihovny už nebudou moct rozhraní API volat. Například změna podpisu metody přidáním nového parametru způsobí, že sestavení zkompilovaná podle starší verze knihovny vyvolají chybu MissingMethodException.

Binární změna způsobující chybu může také přerušit celé sestavení. Přejmenováním sestavení AssemblyName se změní identita sestavení, stejně jako přidání, odebrání nebo změna silného klíče pojmenování sestavení. Změna identity sestavení přeruší veškerý zkompilovaný kód, který ho používá.

❌ NEMĚŇTE název sestavení.

❌ NEPŘIDÁVEJTE, NEODSTRAŇUJTE ani NEMĚŇTE silný klíč pro pojmenování.

✔️ ZVAŽTE použití abstraktních základních tříd místo rozhraní.

Přidání čehokoli do rozhraní způsobí selhání existujících typů, které ho implementují. Abstraktní základní třída umožňuje přidat výchozí virtuální implementaci.

✔️ ZVAŽTE umístění ObsoleteAttribute typů a členů, které chcete odebrat. Atribut by měl obsahovat pokyny k aktualizaci kódu, aby se zastaralé rozhraní API již nepoužívalo.

Kód, který volá typy a metody pomocí ObsoleteAttribute vygeneruje upozornění sestavení se zprávou zadanou atributem. Upozornění dávají lidem, kteří používají zastaralé rozhraní API, čas na migraci, aby po odstranění zastaralého rozhraní API většina z nich přestala toto rozhraní používat.

public class Document
{
    [Obsolete("LoadDocument(string) is obsolete. Use LoadDocument(Uri) instead.")]
    public static Document LoadDocument(string uri)
    {
        return LoadDocument(new Uri(uri));
    }

    public static Document LoadDocument(Uri uri)
    {
        // Load the document
    }
}

✔️ ZVAŽTE zachování typů a metod s ObsoleteAttribute neomezenou dobou v knihovnách nízké a střední úrovně.

Odebrání rozhraní API je zásadní změna struktury. Zvažte zachování zastaralých typů a metod, pokud jejich udržování stojí málo a nepřidává hodně technického dluhu do vaší knihovny. Odebráním typů a metod se můžete vyhnout výše uvedeným scénářům nejhoršího případu.

Další informace o tom, jaké změny rozhraní .NET API přeruší binární kompatibilitu, naleznete v tématu Kompatibilita veřejných kontraktů .NET.

Viz také

Předchozí

  • Last updated on