Publikując artykuł na temat "małych" i "dużych" byłem ciekawy opinii innych ludzi z branży. Pierwszy odzew otrzymałem od kolegi ze studiów Marka Kozłowskiego i za jego zgodą przedstawiam go poniżej. Marek po przeczytaniu postu wyraził zdziwienie, że taki temat w ogóle pojawił się w rozmowie, a rozbicie kodu na podprojekty jest dla niego czymś naturalnym i oczywistym. Stwierdził również, że nie wyobraża sobie pracy z jednym dużym projektem (Aspekt psychologiczny), na który składa się na przykład 100 p...

W .NET mamy do dyspozycji wygodny mechanizm do zapisywania ustawień aplikacji. Nie będę tutaj opisywać podstaw obsługi tego mechanizmu. Osoby niezaznajomione z tym mechanizmem odsyłam do dokumentacji. W tym wpisie skupię się na stworzeniu własnego dostawcy ustawień. Domyślnym i jedynym standardowo dostępnym dostawcą, który zajmuje się zapisem ustawień jest LocalFileSettingsProvider. Dostawca ten zapisuje pliki do lokalnego katalogu u...

Małymi kroczkami, dotarłem do miejsca, w którym czas złapać za klawiaturę i zacząć pisać kod. Plan działania (pierwsza pięciolatka) wygląda następująco: import i parsowanie danych ze strony sejmu, obliczanie różnych statystyk na podstawie zgromadzonych danych, warstwę dostępu do bazy danych i UI w formie strony internetowej. Uszeregowałem sobie zadania od najtrudniejszego do najłatwiejszego, przynajmniej teoretycznie. Na pierwszy ogień idzie import i parsowanie danych ze strony sejmu. Fasadę procesu impo...

Dziś chciałbym opisać kolejny wzorzec/mechanizm który będę używal i ma on na celu znaczne uproszczenie kodowania i eliminowanie niepotrzebnych powiązań miedzy obiektami. Event Aggregator Jak już wcześniej wspomniałem ten wzorzec/mechanizm ma na celu eliminowanie niepotrzebnych powiązań miedzy obiektami. Stanowi on pojedyncze źródło dla wielu obiektów. W najprostszej formie wygląda to tak że rejestrujemy klasy które dotyczą konkretnego zdarzenia do naszego event aggregatora. Te klasy nazywają się uchwyt...

Szkoda, że w C# nie ma znanych z Javy anonimowych klas. Nie mylić z anonimowymi typami, które nie pozwalają na implementację metod! W internecie jest wiele skarg i próśb próbujących wymusić na Microsofcie dodania tego, jakże wygodnego, ficzera do naszego języka...

Generyczna klasa zbioru W projekcie, nad którym pracuję potrzebowałem przyzwoicie działającej klasy reprezentującej zbiór. Zbiór nie do końca w sensie teoriomnogościowym (o właściwościach takiego można przeczytać np. tu), posiadający jedną bardzo ważną cechę: przechowywanie unikalnych elementów. Istniejące implementacje (Hashtable oraz HashSet) nie spełniały moich oczekiwań – elementów do wstawiania było na tyle dużo, że występowały kolizje z obliczonej przez GetHashCode() wartości. Ponieważ rozwiązanie...

O Fluent Interface ("płynnym interfejsie"?:) ) jest od jakiegoś czasu dość głośno w światku .NET. Stał się... trendy. Implementują go właściwie wszystkie kontenery IoC, można za jego pomocą skonfigurować NHibernate, coraz więcej innych projektów udostępnia swoje API w ten sposób. Ale dlaczego, czy jest to naprawdę tak fajne? Moim zdaniem: TAK. Fluent Interface jest nawet czymś więcej niż "fajnym bajerem" - pozwala naprawdę bardzo uprościć pracę z naszą biblioteką.

ASP .NET MVC jest frameworkiem wspierającym wzorzec projektowy MVC. Należy zdawać sobie sprawę, że przechodząc z klasycznego ASP .NET na ASP .NET MVC tracimy możliwość korzystania ze zbioru kontrolek typu ListView, Repeater itp. Na początku może wydawać się to bardzo ograniczające jednak w praktyce czas wymagany na stworzenie aplikacji webowej jest niewiele dłuższy a za to zyskujemy znacznie większą elastyczność. Ponadto ze względu na brak standardowych kontrolek nie ma bałaganu z ViewState. Uogólniając,...

Warstwa prezentacji odpowiedzialna jest za komunikację z użytkownikiem. W dzisiejszych czasach interfejsy graficzne są na tyle rozbudowane, że poprawne zaprojektowanie warstwy prezentacji stanowi poważne wyzwanie. W małych projektach często ta warstwa stanowi najbardziej złożoną część całej architektury. Bez wykorzystania stosownych wzorców projektowych po pewnym czasie pisania aplikacji okaże się, że jakakolwiek zmiana interfejsu wiąże się ze skomplikowaną refaktoryzacją kodu. Jedną z podstawowych cec...

Zasada mówi żeby tworzone przez programistę interfejsy były odpowiedzialne za jak najmniejsza funkcjonalność. Użytkownik chcąc zaimplementować taki interfejs nie powinien pisać metod, których nie potrzebuje. Jeśli znajdują się w nim niepotrzebne metody to wtedy nazywamy go interfejsem “fat” lub “polluted”. Najlepiej rozważyć to na klasycznym przykładzie (z oodesign):interface IWorker { void Work(); void Eat(); } class Worker: IWorker { publicvoid Work() { } publicvoid ...