Posts tagged oss projects
DDDSample.Net 0.5
Dec 4th
Śpieszę donieść, że właśnie pojawiła się nowa (0.5) wersję projektu DDDSample.Net. Ponieważ dawno o DDDSample nie pisałem, pozwolę sobie przypomnieć, co to takiego ten projekt i jaki jest jego aktualny stan. Projekt jest portem Java-owego DDDSample, demonstracją siły podejścia Domain-Driven Design w projektowaniu aplikacji biznesowych.
Obecnie funkcjonalności biznesowe obejmują:
- Rejestrację nowego towaru do spedycji
- Wyznaczenie (niekoniecznie) optymalnej trasy transportu
- Rejestrację nowego “zdarzenia” transportowego (np. odebrano towar, załadowano towar)
- Śledzenie postępu transportu
Interfejs użytkownika zbudowany jest w oparciu o ASP.NET MVC. Komendy użytkownika przekazywane są, za pośrednictwem warstwy aplikacji dokonującej translacji żądań, do Modelu Domeny. Model zawiera całość logiki aplikacji. Podzielony jest na 3 główne obszary (zwane agregatami):
- Location – zawierający logikę związaną z lokalizacją – jest to właściwie generyczna poddomena.
- Cargo – zawierający logikę związaną z rejestracją, wyznaczaniem trasy oraz śledzeniem postępu transportu
- Handling – zawierający logikę związaną z rejestracją zdarzeń transportowych
Począwszy od wersji 0.5 komunikacja pomiędzy dwoma ostatnimi agregatami zrealizowana jest asynchronicznie, z wykorzystaniem NServiceBus. Co nam to daje? Podstawowe wykorzystanie agregatu Cargo to odczyt danych (na potrzeby śledzenia postępu). Podstawowe wykorzystanie agregatu Handling to zapis danych (na potrzeby rejestracji zdarzeń). Dzięki oddzieleniu tych dwóch możemy zastosować różne sposoby skalowania w tych dwóch obszarach systemu. A to tylko jeden z wielu przykładów…
Zapraszam do ściągnięcia DDDSample.Net i poeksperymentowania. Projekt dostępny jest w formie instalatora MSI (w sekcji downloads) lub w formie źródeł. MSI nie instaluje źródeł, a jedynie aplikację ASP.NET.
DDDSample.Net żyje!
Oct 5th
Z ogromną przyjemnością śpieszę donieść, iż projekt DDDSample.Net – .NET-owy klon projektu DDDSample – właśnie doczekał się pierwszej wersji. Wraz z projektem powstał także stosowny blog, na którym publikowane będą informacje dotyczące postępu prac oraz posty komentujące decyzje projektowe, które zostały podjęte przez autorów Java-owego oryginału.
Zachęcam wszystkich do ściągnięcia wersji 0.1 DDDSample.Net i pokeksperymentowania z Domain-Driven Design. Nie będziecie żałować!
Mentoring DDD: NHibernate 2 Fetching Strategies
Jul 22nd
Though rare, there are times when an aspiring architect as myself must sit down in front of his computer and write some code. It happens when as an architect wants to use some brilliant idea but later she or he finds out that this idea is really not yet implemented. It happened to me today when I realized that Udi’s fetching strategy idea is implemented (by him) only for NHibernate 1.2.
Udi’s advice for 2.* users is to download Ayende’s Repository package and use it. Unfortunately my specific case did not allowed for that because my compandy developed an in-house abstraction later over O/RM and it would be very cumbersome to integrate it with repositories. So I was presented with choice of:
- giving up on using fetching strategies at all and face potential performance problems
- rolling back to NHibernate 1.2
- implemneting fetching strategies for NHibernate 2 myseft
As you can gues from title of this post, I have chosen the third alternative.
NHibernate 2 model for ISession implemention is totally differend from the one of 1.2 version: it is based on events. On one hand it allowed me to implement fetching strategies without modifieing NHibernate source code. On the other, it required me to rethink some concepts from Udi’s code.
Full source code can be downloaded from here.
Key concepts of this package include:
- As in Udi implementation, fetching strategies are defined by implementing generic interface IFetchingStrategy
where T is an interface which is requested from session to be fetched (for details read this gread post). - Fetching strategy implementations are found using helper class with an event rising when strategies are needed. It alows to register more than one source of fetching strategies. Common usage is, however, to wire the event with lookup in your favourite container or service locator, possibly through Common Service Locator.
The quality of this code is not yet production-ready, but it will increase during following days and as bugs will be found and fixed I will post new versions of the source code. Do not hesitate to ask any questions or inform about bugs/issues in comments of this post.
NetMX
Jun 4th
Sam się dziwie sobie, że jeszcze nic nie napisałem na temat tego projektu. Właściwie to byłem w ciężkim szoku, kiedy przejrzałem listę dotychczasowych notek i nie znalazłem tam wzmianki o NetMX. A to przecież mój pierwszy projekt open source:) Brał nawet udział w konkursie. Właściwie dzięki niemu poznałem Zine-a. I trafiłem do Zine-a. Naprawdę, wiele zawdzięczam NetMX-owi. Należy mu się wreszcie jakaś notka.
Przerywnik marketingowy: NetMX-a możecie sobie zupełnie za darmo ściagnąć stąd.
Co to takiego?
W telegraficznym skrócie, NetMX, a właściwie .NetMX, to port JMX dla .NET. Całkiem logiczne, prawda? No to teraz dla nie znających JMX: NetMX jest frameworkiem służacym do (zdalnego) zarządzania i monitorowania aplikacjami tworzonymi w technologii .NET.
Co to potrafi?
Pozwala na dostęp, czyli
- przeglądanie i edycję atrybutów
- wykonywanie operacji (także parametryzowanych)
- przechwytywanie zdarzeń
za pomocą webowego interfejsu użytkownika (ASP.NET) do tzw. obiektów zarządzanych, czyli obiektów waszej aplikacji, które zostały zarejestrowane w serwerze NetMX.
Jakie obiekty mogą być obiektami zarządzalnymi? Dowolne. Jedynym wymaganiem jest, aby implementowały specjalny interfejs, który potrzebny jest do tego, aby stwierdzić które ficzery obiektu (operacje, atrybuty, zdarzenia) mają być udostępniane przez NetMX. Te ficzery, które nie są zadeklarowane na interfejsie, nie będą eksponowane. Istnieje także możliwość stworzenia dynamicznych obiektów zarządzanych. W takim wypadku implementujemy specjalny interfejs i sami określamy co się ma dziać, kiedy na przykład klient wywoła operację “xxx”. Lista ficzerów udostępnianych przez obiekty dynamiczne może się zmieniać w trakcie ich życia.
A po co mi to?
…skoro Microsoft daje WMI. W momencie rozpoczynania projektu NetMX wsparcie dla WMI pod .NET było, delikatnie mówiąc, mizerne. Nawet dziś nie jest ono najlepsze. WMI jest bardzo ciężką, niezarządzaną, technologią. Konfiguracja wymaga wsparcia ze strony administratorów. No i generalnie, przeznaczone jest do monitorowania i zarządzania od strony technicznej. NetMX jest bardzo lekki. Jest w pełni zarządzalny. Serwer NetMX działa w ramach pojedynczego procesu, więc jego konfiguracja leży w pełni w gestii twórcy systemu, który go używa. Głównym przeznaczeniem NetMX jest udostępnianie interfejsu zarządczo-monitoringowego dla administratorów biznesowych aplikacji. NetMX pozwala np. na monitorowanie statystyk przetwarzania w podziale według kryteriów biznesowych.
Jak to działa?
Dokładnie tak samo, jak Java-owy pierwowzór. Rozumiem, że to nie wiele wyjaśnia:) NetMX operuje na tzw. MBean-ach, czyli obiektach zarządzanych. Jak już wspomniałem, takim obiektem może być obiekt praktycznie dowolnej klasy. Obiekty te są rejestrowane w serwerze (MBeanServer). Jest to rodzaj kontenera. Umożliwia on wyszukiwania MBean-ów po nazwie lub atrybutach. Umożliwia także interakcję z MBean-ami. Nie udostępnia, za to, referencji do instancji MBean-ów. Wszelkie interakcje z nimi (pobieranie i edycja atrybutów, wykonywanie operacji) realizowane są za pośrednictwem serwera. Serwer umożliwia także zapisywanie się na zdarzenia publikowane przez MBean-y. Zapisywać można się zarówno z zewnątrz serwera (poprzez przekazanie callback-u), jak i z wewnątrz (wtedy to innym MBean jest nasłuchującym).
Jest to podstawowa funkcjonalność NetMX. Ponad nią zbudowany jest cały zestaw dodatkowych ficzerów:
- Dostęp zdalny (za pomocą Remoting-u lub (nowość!) webserwisów WS-Management)
- Proxy – tworzenie zdalnych odpowiedników MBean-ów ułatwiających wykonywanie na nich operacji
- OpenMBean – rozszerzenie specyfikacji pozwalające na przekazywanie dodatkowych metadanych w celu lepszej prezentacji MBean-ów na GUI
- Relacje – możliwość definiowania dowolnych relacji łączących MBean-y. Relacje umożliwiają np. nawigowanie między MBean-ami na GUI
Kończąc tę notkę zachęcam was do ściągnięcia NetMX i przyjrzenia się przykładom demonstrującym możliwości tego frameworka. Ja osobiście chętnie pomogę (konsultację) przy pierwszych wdrożeniach NetMX w Waszych systemach (jeśli się na taki krok zdecydujecie).
Not invented here
Feb 5th
Większość z Was pewnie wie doskonale co oznaczają trzy słowa w tytule. Pozostałych odsyłam tutaj. Prawie każdy programista na pewnym etapie swojego rozwoju (o którym świetnie piszę Procent tu, tu i tu) cierpi na chorobę pisania wszystkiego od nowa. Wydaje mi się, że wynika to z ogromnej pychy, która jest niezbywalną cechą programistów – “przecież ja zrobiłbym to lepiej!”. Łatwo potępiać takie postępowanie, kiedy patrzy się na nie z perspektywy wielu lat doświadczenia – że bez sensu, że szkoda czasu, że przecież są ludzie mądrzejsi.
Tu mała dygresja, żeby nie pozostawiać wątpliwości – szczerze nienawidzę syndromu “not invented here” w odniesieniu do inżynierii oprogramowania jako dziedziny przemysłu. NIH w firmach nie sprawdza się prawie nigdy.
Z drugiej strony jednak uważam, że podejście to ma swoje zalety i, odpowiednio zastosowane, może być wartościowe. Według mnie “not invented here” drzemiące gdzieś w zakamarkach duszy programisty zachęca go do podejmowania twórczych działań w celu zmiany otaczającego go świata. Być może delikwent taki nie napisze od postaw kolejnego framework-u Dependency Injection, ale zrobi coś, aby ten, którego używa był lepszy. A wszystko po to, aby uciszyć wyrzuty sumienia, w którym tkwi ziarno “not invented here”.
Kolejną zaletą wymyślania koła na nowo jest fakt, że jest to świetna metoda nauki nowych technologii i koncepcji. Żadna książka i żadne szkolenie nie zastąpi zaimplementowania dobrze znanej funkcjonalności za pomocą nowej technologii.
I tym optymistycznym akcentem chciałbym zaanonsować nowy cykl notek na tym blogu: moja własna szyna usług. Temat ten został ostatnio spopularyzowany przez Ayende Rahien, który pogardził nServiceBus Udiego Dahana oraz MassTransit-em i podjął się budowy własnej szyny. Idąc więc za ciosem, ja również będę miał własną szynę. A co!?!:)
