1 / 24

Komponentowe i rozproszone

Komponentowe i rozproszone. Komponenty i zależności. Moduł. Obecne rozwiązania pozwalają łatwo dzielić kod na moduły Nie utrudnia to kompilacji , łatwo zmienić rozmieszczenie klas itd . Serwery CI pozwalają wykrywać niespójności pomiędzy modułami

nigel-phelps
Download Presentation

Komponentowe i rozproszone

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Komponentowe i rozproszone Komponentyizależności

  2. Moduł • Obecnerozwiązaniapozwalająłatwodzielićkodnamoduły • Nieutrudnia to kompilacji, łatwozmienićrozmieszczenieklasitd. • Serwery CI pozwalająwykrywaćniespójnościpomiędzymodułami • Nie ma dużejróżnicyczydostarczamy program w postaci 1 plikuwykonywalnegoczygrupyplików. Na potrzebyinstalacjimożnascalićkilka assemblies w jednonp (exe+dll-ki -> exe) • Na poziomiekoduitakdążymy do rozluźnieniazależnościmiędzyklasami, użycieróżnych assemblies jest właściwie “bezbolesne” • Rozwiązaniatypukontenery DI pozwalająnarozluźnieniezależnościmiędzyklasami

  3. Komponent • Co jeżelichcemydostarczaćposzczególnemodułyoddzielnie? • Jaktestowaćkomponent, którymożebyćużywany w kilkusystemach/aplikacjach? • Co jeżelikażdyużytkownikchcemiećswojezmiany ? • Co jeżelizmianazaindukowanaprzezjeden system wymuszatestowaniekoduzewszystkimi? • Czyliprzykażdejzmianietrzebatestowaćwszystkichużytkowników/ ???

  4. Komponenty vs. moduły • Komponent • Jest dostarczanyniezależnie • ma indywidualnycyklżycia/testowaniaitd • Poszczególniużytkownicymogąużywaćswoichwersji. • Mogąsię “przesiąść” nanowsząwersję w wybranym, dogodnymmomencie (jakrobiąwłasnezmiany) • Możnawersjonowaćkomponentynapoziomiebinarnym

  5. .Net • CLI pozwalanawykorzystywaniekodunapisanego w dowolnymjęzykuwspierającym .NET • Zarządzalnebiblioteki w połączeniu z refleksjąpozwalająnałatweużyciekodunapoziomiebinarnym (CL) • Wersjonowaniepozwalanajednoczesneużycieróżnychwersjitejsamekjbiblioteki • Na poziomiesystemowymmożnarejestrowaćbiblioteki w GAC

  6. .Netvs Java • …. • JNBridge • IKVM • WebServices ?

  7. Uwaga Komponent ≠ Serwis

  8. .NET Podzespoły(assemblies) • Logiczny zbiór jednego lub więcej EXE, DLL • Wydzielone pliki z zasobami • Manifest • Definiowanie podzespołu: • AL.EXE (ILDASM.EXE) • IDE

  9. .NET Manifest • Definiuje obiekty wchodzące w skłąd podzespołu • Może określać kulturę (język, formaty, itd) • Może zawierać klucze publiczne • Może zawierać prywatne atrybuty (ignorowane przez CLR) • Może określać wymagany/pożądany CLR

  10. .NET wdrażanie podzespołów • Podzespołymogąbyćwspółdzielneimogąwspółdzielićpliki • Najprostszapostać to pliki w jednymkatalogu(niewymaganeżadnewpisy do rejestru) • Brakew. konfliktów • Pot. multiplikacjabibliotek • Współdzieleniezasobów: • GlobalAssemblyCache (GACUTIL.EXE, AssemblyCacheViewer) • Wamagasilnychnazw: Nazwa+fragmentkluczapublicznegoSN.exe -> plik.snk -> projekt

  11. .NET Wersjonowanie • AlternatywadlapiekłaDLLi • „Docelowyplik jest nowszyniżkopiowany. Czykontynuować ?” (9()% - TAK) • Manifest zawierainformację o wersji • Głównyidrugorzędnynumerwersji • Numerkompilacji • Numerkorekty • Manifest zawierawersjęinformacyjną • CLR próbujeznaleźćwersjepodzespołówwymaganelubdopuszczaneprzezklienta

  12. .Net: Global Assembly Cache • Rejestracja/derejestracja • gacutil [options] [assemblyName | assemblyPath | assemblyListFile] • Assembly musibyćpodpisane

  13. Zależności • Rodzajezależności: • (Afferent) - ktozależy • (Efferent) – odkogozależy efferent classY{ … } class X{ … Y field; } afferent

  14. Podziałnakomponenty • REP: The Reuse/Release Equivalency Principle: The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package. • CRP: Common Reuse Principle:The classes in a package are reused together. if you reuse one of the classes in a package, you reuse them all. • CCP: Common Closure Principle:The classes in a package should be closed together against the same kinds of changes. a change that affects a package affects all the classes in that package. Robert C. Martin

  15. Komponent REP: Grupowaniedlareużycia CCP: Grupowaniedlapotrzebutrzymania Zbędnereleasy Kompo-nent Zmianyrozproszonemiędzykomponentami Niewygodne (re)użycie CRP: podziałdlauniknięciazbędnychreleasów Granicepodziałudeterminujączęstośćreleasów, wygodędevelopmentuikorzystania z komponentu

  16. Zależnościmiędzymodułami • Acyclic Dependencies Principle: the dependency structure between packages must be a directed acyclic graph (dag). that is, there must be no cycles in the dependency structure. • Stable Dependancies Principle:the dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is. • Stable Abstractions Principle: packages that are maximally stable should be maximally abstract. instable packages should be concrete. The abstraction of a package should be in proportion to its stability. Robert C. Martin

  17. Miarazależności • CA (X) = liczbafunkcji/klas/modułów, którezależąod (odwołująsie do) X • CE (X) = liczbafunkcji/klas/modułów do którychodwołujesię X • N = liczbatypów • NA = liczbatypówabstrakcyjnych • Niestabilność: I =CE / (CA+ CE) • Abstakcyjność: A=NA/N

  18. Stabilność Modułystabilne (trudne do zmiany) niepowinnyzależećodniestabilnych (łatwych do zmiany) • Co jest łatwe do zmiany? Klasyfinalne, do którychniewielekodusięodwołuje. • Co jest trudne do zmiany? Klasyfinalne, do którychodwołujesiędużokodu, klasybazowe, interfejsy. • Co zmieniasięczęsto: klasykonkretne, implementacjelogikibiznesowej • Co zmieniasięrzadko: abstrakcje – interfejsy, klasyabstrakcyjne

  19. Optymalnasytuacja A 1 Strefabrakuużyteczności: klasyabstakcyjne, z którychniktniekorzysta Klasyczystoabstrakcyjne o dużejstabilności 1 I Strefabólu: klasykonkretne, b. częstoużywane w kodzie Klasykonkretne o małejstabilności Miara pot. problemów: D = |A+I-1|

  20. Wiecej nt. komponentów • Robert C. Martin - Clean Design, Components Principles.wmv

  21. Rozszerzalna architektura z MS • KonteneryIoC/DI • Wieledostępnychrozwiązań • Decoupling, testowanie, scentralizowanarejestracja, • MEF • Wprowadzony w .Net 4.0 • Discovery, obsługametadanych, opóźnionakreacja

  22. MEF - koncepcja

  23. MEF – Podstawowe pojęcia • Export • Export dlatypu/funkcji/pól • Wymuszonytyp: Export(typeof(Ixxx)) • Nazwanykontrakt: Export("name",typeof(Ixxx)) • Export nie jest dziedziczony – możnaużyćInheritedExport • Import • Dlatypuokreślonego w kodzie • Import określonegotypu/kontraktu

  24. MEF – Zalecane praktyki • Imort/EksportInterfejsówzamiastkonkretnychtypow • Stałejakonazwykontraktow • stale/ikontrakty w oddzielnych assembly

More Related