Producenci kontrolek lubią kiedy kupujemy kontrolki bo mają z tego pieniądze, nierzadko duże pieniądze. Jeszcze bardziej cieszą się jak podziedziczymy po ich kontrolkach. Wtedy jesteśmy ich, na zawsze. Jesteśmy jak narkoman w rękach dilera. Dlaczego? Ano dlatego, że jeśli odziedziczymy coś po jakiejś kontrolce lub bibliotece, a jeszcze lepiej jeśli kawałek kodu, który dziedziczy należy do logiki biznesowej lub logiki aplikacji to późniejsza zmiana kontrolki wiąże się z przerobieniem większości aplikacji i wymaga sporo pracy. Nierzadko może dochodzić do sytuacji gdzie takie wyrugowanie jest nawet niemożliwe (czytaj. nieopłacalne z punktu widzenia projektu). A dlaczego porównanie do dilera? Ano dlatego, że jak znajdziemy się w takiej sytuacji to musimy prawie każdą wersję kontrolek kupować i płacić wielkie ilości siana co roku czy co wersję czy jaki tam inny model krojenia dev-ów mają ee…. model licencyjny się znaczy.
Czy zatem nie powinno się stosować zewnętrznych komponentów? Czy NIH (not invented here) jest zatem dobry? Daleki jestem od tego. Uważam, że zawsze trzeba zrobić kalkulację zysków i strat, sprawdzić co bardziej się opłaca. Często kupno zewnętrznej biblioteki jest dużo tańsze niż wyprodukowanie jej wewnątrz organizacji.
Jak się chronić?
Zakładając, że kupujemy zewnętrzne kontrolki/biblioteki, jak się chronić przed uzależnieniem? Enkapsulować, enkapsulować, enkapsulować. Tak samo jak dane pakujemy w klasy tak funkcjonalność biblioteki zapakujmy do jakiejś klasy. Jeśli stworzymy interfejs IExcelExporter i klasę ExcelExporterFromXXXCompany implementującą interfejs IExcelExporter, to w całej naszej aplikacji wiążemy się jedynie z IExcelExporter. Konkretna klasa ExcelExporterFromXXXCompany jest jedną z możliwych jakie możemy wykorzystać. Dzisiaj może tam enkapsulować kontrolkę z firmy A, jutro z firmy B. Jakkolwiek, zmiana dostawcy będzie wymagała pracy, to z punktu widzenia naszej aplikacji do zmiany będziemy mieli jedną lub kilka pojedynczych klas a nie będzie trzeba przerabiać całości.
Warstwy
Dobrze zrestrukturyzowana aplikacja składa się z warstw. W najprostszej postaci mamy:
-
warstw dostępu do danych (DAL)
-
logikę biznesową
-
logikę aplikacji
-
interfej użytkownika (UI)
Jeśli potrzebujemy referencji do zewnętrznej biblioteki w każdej warstwie (np. do kontrolek interfejsu użytkownika) to wiedz, coś jest źle…. bardzo źle.
Kontrolki a dług technologiczny
Mam wątpliwości czy ten artykuł wrzucać pod dług technologiczny czy nie, dlatego ocenę tego pozostawiam Tobie. Trzeba jednak pamiętać, że Kupno zewnętrznej biblioteki zamiast tworzenia funkcjonalności samodzielnie z jednej strony kosztuje nasze pieniądze a z drugiej strony pozwala szybko uzyskać w miarę pożądany efekt bez wynajdywania koła na nowo. Jeśli kontrolkę użyjemy mądrze to nie będzie ona stanowiła długu, jeśli źle to się nim stanie. Wybór należy do Ciebie.
A jeżeli dotarłeś do tego miejsca ale ciągle myślisz “o czym ten koleś marudzi” to proszę sobie przypomnieć ile było szumu o to, żeby obiekty z Entity Framework były POCO i nie dziedziczyły po czymkolwiek*
*) tak, wiem, wielu z powie że to nie o to chodzi 
