Featured Image
Nov 28, 2010 1 min read 0 comments

[PL] Podsumowanie konkursu “Daj się poznać”

W końcu udało mi się znaleźć chwilę czasu, żeby napisać małe podsumowanie. Konkurs zakończył się już prawie dwa tygodnie temu. Udało mi się wyrobić niezbędne minimum, żeby przejść dalej. Do dnia dzisiejszego blog miał 4 910 wizyt. W tym tygodniu zakończył się zamknięty etap głosowania. Również i tym etapie udało mi się przejść dalej. Dziękuje wszystkim za oddane głosy na mój blog. Teraz odbywa się publiczne głosowanie, które zakończy się już niedługo. Sam swój udział w konkursie uważam za średnio udany. Projekt co prawda ruszył się troszkę do przodu, ale nie jestem jednak zadowolony z postępów prac 🙂 Jednak udało mi się zrobić jedna rzecz, na której najbardziej mi zależało – przenieść dane programu do bazy SQLite. Projekt będzie dalej rozwijany po zakończeniu konkursu. Mam zamiar wypuścić w końcu nowa wersję. Pisanie nowych postów na blogu również mam w planach. Blogowanie spodobało mi się po prostu 🙂 Ogólnie jestem bardzo zadowolony, że wziąłem udział w konkursie. Poznałem dzięki temu sporo nowych narzędzi i technologii oraz spróbowałem swoich sił jako bloger.

Featured Image
Nov 7, 2010 2 min read 1 comments

[PL] Entity Framework – POCO i Repository generator

W Entity Framework 4 została dodana obsługa klas POCO. Samo pisanie takich klas oraz odpowiedniej klasy dziedziczącej po ObjectContext (klasa ta zapewnia "most" pomiędzy klasami POCO a EntityFramework) może być czasochłonne. Na ratunek przychodzi jednak POCO Entity Generator. Po jego instalacji wystarczy przejść do edytora naszego modelu, otworzyć menu kontekstowe, wybrać "Add Code Generation Item…", a następnie w nowo otwartym oknie wybrać "ADO.NET POCO Entity Generator". Po krótkiej chwili w danym projekcie pojawią się nowe pliki: W tych plikach zostały zawarte klasy POCO, stworzone na podstawie naszego modelu. Niestety przedstawiony generator ma jedną wadę. Musi być on umieszczony razem w jednym projekcie z modelem EF. Jeśli chcielibyśmy stworzyć prawdziwe klasy POCO, należałoby by je umieścić w osobnym projekcie – warstwie encji biznesowych. Kolejnym pomocnym generatorem jest Repository Generator. Jak nazwa wskazuje generator ten tworzy klasy repozytoriów. Po ściągnięciu generator należy dodać go do projektu poprzez wywołanie z menu kontekstowego projektu opcji Add -> Existing Item. Po dodaniu generatora, stworzone zostaną odpowiednie klasy repozytoriów: Generator tworzony jedno repozytorium na daną klasę zawartą w modelu. Dla każdego repozytorium stworzone zostały dwa pliki. Jeden to plik zarządzany przez generator. Z kolei w drugim pliku możemy rozbudować dane repozytorium o nasze potrzeby i nie martwić się, że generator nadpisze zmiany. Przedstawione w tym poście generatory z pewnością uprzyjemnią i przyśpieszą pracę z Entity Framework 🙂

Featured Image
Nov 7, 2010 3 min read 3 comments

[PL] MEFedMVVM – integracja z Unity

Ostatnio interesowała mnie sprawa użycia Unity razem z biblioteka MEFedMVV. Czemu w ogóle rozważałem taka kwestię? Otóż MEF pozwala jedynie zdefiniować na dwa sposoby jak dany obiekt ma być tworzony – czy będzie to jeden obiekt, czy obiekt będzie tworzony za każdym razem. Jeśli chcielibyśmy stworzyć jakieś bardziej zaawansowane reguły tworzenia obiektów (np. tworzenie nowego obiektu tylko dla danego wątku), wtedy musimy posłużyć się już jakimś kontenerem IoC/DI. Na szczęście ktoś już o tym pomyślał i została stworzona biblioteka MefContrib. Pozwala ona m.in. na integrację Unity z MEF’em. Integracja może przebiegać na trzy różne sposoby: MEF "widzi" typy zdefiniowane w Unity, ale Unity nie "widzi" typów zdefiniowanych w MEF’ie, Unity "widzi" typy zdefiniowane w MEF’ie, ale MEF nie "widzi" typów zdefiniowanych w Unity, MEF i Unity "widzą" wzajemnie zdefiniowane typy. Omówię tutaj przypadek ostatni. W celu dokonania takiej integracji należy wykonać jedynie 3 linijki kodu: UnityContainer unityContainer = new UnityContainer(); AssemblyCatalog assemblyCatalog = new AssemblyCatalog(Assembly.GetExecutingAssembly()); unityContainer.RegisterCatalog(assemblyCatalog); I to właściwie wszystko co trzeba zrobić, żeby zintegrować MEF’a z Unity. Problemem pozostaje teraz jak to połączyć z biblioteką MEFedMVVM. Niestety MEFContrib oraz MEFedMVVM tworzą instancję klasy CompositionContainer wewnętrznie i nie ma możliwości aby przekazać taką instancję z zewnątrz. Jedyną opcję na konfigurację daję nam MEFedMVVM i jego klasa LocatorBootstrapper. Trzeba tutaj do metody ApplyComposer przekazać instancję klasy, która implementuje interfejs IComposer. Całość kodu przedstawia się następująco: public class SampleComposer : IComposer { private ComposablePartCatalog catalog; private IEnumerable<ExportProvider> exports; public SampleComposer(ComposablePartCatalog catalog, IEnumerable<ExportProvider> exports) { this.catalog = catalog; this.exports = exports; } public IEnumerable<ExportProvider> GetCustomExportProviders() { return this.exports; } public ComposablePartCatalog InitializeContainer() { return this.catalog; } } public partial class App : Application { protected override void OnStartup(StartupEventArgs e) { UnityContainer unityContainer = new UnityContainer(); AssemblyCatalog assemblyCatalog = new AssemblyCatalog(Assembly.GetExecutingAssembly()); unityContainer.RegisterCatalog(assemblyCatalog); unityContainer.RegisterType<IHelloWorldService, HelloWorldService>(); CompositionContainer container = unityContainer.Resolve<CompositionContainer>(); SampleComposer sampleComposer = new SampleComposer(assemblyCatalog, new List<ExportProvider>() { container }); LocatorBootstrapper.ApplyComposer(sampleComposer); } } Stworzyłem klasę SampleComposer, która zajmuje się przekazaniem zdefiniowanych typów w Unity do biblioteki MEFedMVVM. Zdefiniowana została też prosta klasa HelloWorldService, która wygląda następująco: public class HelloWorldService : IHelloWorldService { public HelloWorldService() { } public string GetMessage() { return "Hello world at: " + DateTime.Now.ToString(); } } Została ona użyta w klasie MainViewModel: [ExportViewModel("MainViewModel")] [PartCreationPolicy(CreationPolicy.NonShared)] public class MainViewModel : INotifyPropertyChanged { private IHelloWorldService helloWorldService; private SimpleCommand<object, object> helloWorldCommand; public event PropertyChangedEventHandler PropertyChanged; public SimpleCommand<object, object> HelloWorldCommand { get { return this.helloWorldCommand; } } public string Message { get; set; } [ImportingConstructor] public MainViewModel(IHelloWorldService helloWorldService) { this.helloWorldService = helloWorldService; this.helloWorldCommand = new SimpleCommand<object, object>(this.ShowHelloWorld); } private void ShowHelloWorld(object param) { this.Message = this.helloWorldService.GetMessage(); this.OnPropertyChanged("Message"); } private void OnPropertyChanged(string propertyName) { if (this.PropertyChanged != null) this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } Konstruktor tej klasy został oznaczony atrybutem ImportingConstructor, który informuje MEF’a o konieczności "wstrzyknięcia" odpowiednich instancji. Typ HelloWorldService został natomiast zarejestrowany w Unity. Jednak dzięki przedstawionej wcześniej integracji MEF "widzi" ten typ. Przedstawiony w tym poście kod został stworzony na podstawie projektu z wcześniejszego wpisu. Tutaj znajduje się jego rozbudowana wersja, stworzona na potrzeby tego wpisu.

Featured Image
Oct 31, 2010 1 min read 2 comments

[PL] NuGet – manager pakietów dla .NET

NuGet jest managerem pakietów dla .NET. Projekt ma na celu ułatwienie dodawania zewnętrznych bibliotek do projektu.  Ma to szczególne znaczenie jeśli biblioteka, której chcemy użyć, używa jeszcze innych bibliotek. Po instalacji NuGet z menu kontekstowego References będziemy mogli wybrać opcję "Add Package Reference": Po wybraniu tej opcji, otworzone zostanie okno dodawania nowego pakietu: W repozytorium znajduje się całkiem spora liczba bibliotek. Właściwie są chyba tutaj wszystkie najbardziej popularne biblioteki. Ja na próbę dodałem referencję do biblioteki Moq. W tym celu jedyne co musiałem zrobić to wcisnąć przycisk "Install" jak na powyższym obrazku. Po krótkiej chwili miałem już dodaną referencję do swojego projektu: Doszedł też nowy plik "packages.config", który przechowuje informacje o dodanych bibliotekach. Sama biblioteka Moq została umieszczona w folderze "packages", w głównym folderze projektu. Dodawanie zewnętrznych bibliotek z NuGet staje się, więc szalenie proste 🙂

Featured Image
Oct 31, 2010 2 min read 2 comments

[PL] Cinch i MEFedMVVM – aplikacja MVVM w 5 min

Ostatnio przeglądałem kilka bibliotek wspomagających tworzenie aplikacji z użyciem wzorca MVVM. Najbardziej do gustu przypadł mi Cinch w wersji V2. Framework ten działa razem z biblioteką MEFedMVVM. Użycie obu bibliotek jest bardzo proste. Najpierw tworzymy klasę, która będzie naszym modelem widoku: [ExportViewModel("MainViewModel")] [PartCreationPolicy(CreationPolicy.NonShared)] public class MainViewModel : INotifyPropertyChanged { private SimpleCommand<object, object> helloWorldCommand; public event PropertyChangedEventHandler PropertyChanged; public SimpleCommand<object, object> HelloWorldCommand { get { return this.helloWorldCommand; } } public string Message { get; set; } public MainViewModel() { this.helloWorldCommand = new SimpleCommand<object, object>(this.ShowHelloWorld); } private void ShowHelloWorld(object param) { this.Message = "Hello world at: " + DateTime.Now.ToString(); this.OnPropertyChanged("Message"); } private void OnPropertyChanged(string propertyName) { if (this.PropertyChanged != null) this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } Do klasy należy dodać atrybut ExportViewModel i przekazać do niego nazwę modelu widoku. Atrybut ten jest zdefiniowany w MEFedMVVM. Biblioteka ta korzysta z MEF, dzięki czemu możemy użyć też atrybutu PartCreationPolicy i ustalić jak nasz model widoku ma być tworzony – czy to będzie jedna dzielona instancja czy model widoku będzie tworzony za każdym razem. Następnie zostało zdefiniowane jedno polecenie przy użyciu SimpleCommand, który jest zdefiniowany w Cinch. Teraz trzeba nasz model widoku powiązać z widokiem. Kod widoku wygląda u mnie tak: <Window x:Class="Cinch_sample.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="MainWindow" Height="350" Width="525" xmlns:meffed="http:\\www.codeplex.com\MEFedMVVM" meffed:ViewModelLocator.ViewModel="MainViewModel"> <Grid> <StackPanel> <TextBlock Text="{Binding Message}" /> <Button Command="{Binding HelloWorldCommand}" Content="Show message" /> </StackPanel> </Grid> </Window> Uwagę trzeba tutaj zwrócić na attached property ViewModelLocator.ViewModel. Podajemy w nim nawę modelu widoku, którego chcemy użyć. I to już wszystko. Aplikacja jest już skonfigurowana i możemy korzystać z dobrodziejstw MVVM. Tutaj znajduje się omawiana w tym poście aplikacja.

Featured Image
Oct 24, 2010 1 min read 2 comments

[PL] VS10x Code Map

VS10x Code Map jest dodatkiem do Visual Studio, który wyświetla graficzną reprezentację bieżącego pliku. W praktyce wygląda to następująco: Po lewej stronie znajduje się graficzna reprezentacja danego pliku. Możemy tutaj zauważyć podział ze względu na zdefiniowane regiony w klasie EditWindowViewModel. Domyślnie dodatek wyświetla elementy danego pliku tak jak są w nim zdefiniowane. Można to zachowanie zmienić poprzez opcje. Po kliknięciu na dany element zostaniemy przeniesieni do jego definicji w kodzie. Regiony można zwijać lub rozwijać – region zostanie również zwinięty/rozwinięty w pliku. Dodatek zapamiętuje również historię nawigacji. Elementy, które odwiedziliśmy wcześniej są odpowiednio zaznaczone w pliku (jako jasno niebieskie tło) oraz w graficznej reprezentacji pliku (jako niebieska ikonka zegarka). Do historii odwiedzonych elementów możemy się dobrać poprzez opcję “Global Solution History” dostępna na samym dole dodatku. Elementy w graficznej reprezentacji można również filtrować po nazwie. W tym celu należy najechać na samą górę dodatku, aż otworzy się odpowiednie pole tekstowe. VS10x Code Map jest moim zdaniem bardzo pomocnym dodatkiem. Brakowało mi właśnie takiej graficznej reprezentacji dla bieżącego pliku. Teraz już to mam 🙂 Jedynym minusem jest to, że nie możemy okna dodatku dowolnie przemieszczać. Jest on związany z oknem edytora pliku.

Featured Image
Oct 24, 2010 3 min read 3 comments

[PL] Entity Framework i śledzenie wykonywanych zapytań SQL

Ostatnio interesowało mnie jakie właściwie zapytania SQL generuje Entity Framework. Chwila na Google i znalazłem Entity Framework Profiler. Najnowszą wersję można pobrać z tego miejsca. Użycie tego narzędzia jest banalnie proste. Najpierw musimy dodać referencję do biblioteki HibernatingRhinos.Profiler.Appender.dll. Następnie gdzieś w punkcie startowym aplikacji umieścić takie polecenie: HibernatingRhinos.Profiler.Appender.EntityFramework.EntityFrameworkProfiler.Initialize(); I to wszystko jeśli chodzi o konfigurację. Wszystkie wykonywane zapytania będziemy mogli śledzić w aplikacji graficznej. Przykładowo mając taką metodę: public IList&lt;Hero&gt; GetHeroes() { return this.heroRepository.All().ToList(); } Metoda (użyty został tutaj wzorzec Repository z poprzedniego posta) zwraca listę wszystkich bohaterów. Po wykonaniu tej metody w EF Profiler zobaczymy coś takiego: Mamy, więc to co chcieliśmy – zapytanie SQL jakie jest wykonywane na bazie danych. Niestety EF Profiler nie jest narzędziem darmowym. Skorzystałem tutaj z 30 dniowej wersji trial. W bardziej zaawansowane możliwości narzędzia nie wgłębiałem się zbytnio ponieważ interesował mnie tylko podgląd zapytań SQL. Na szczęście istnieje darmowy projekt EF Provider Wrappers. Do dyspozycji mamy dwóch dostawców: EFTracingProvider – dostawca umożliwiający podgląd wykonywanych zapytań, EFCachingProvider – dostawca umożliwiający cachowanie wyników zapytań. Ja skorzystałem oczywiście z tego pierwszego. W tym wpisie blogowym znajduje się dobry tutorial omawiający użycie tych dostawców. Ja przedstawię tutaj tylko krótki poradnik jak uruchomić dostawcę EFTracingProvider. Ściągamy projekt dostawców, a następnie go kompilujemy, Dodajemy referencję bibliotek EFTracingProvider.dll oraz EFProviderWrapperToolkit.dll do naszego projektu. Odnajdujemy plik ExtendedNorthwindEntities.cs (znajduje się on w projekcie EFProviderWrapperDemo) i kopiujemy do naszego projektu. Następnie przerabiamy go tak, żeby korzystał z naszej klasy ObjectContext oraz odpowiedniego connection string, Dodajemy do pliku konfiguracyjnego app.config następujący wpis: &lt;system.data&gt; &lt;DbProviderFactories&gt; &lt;add name=&quot;EF Tracing Data Provider&quot; invariant=&quot;EFTracingProvider&quot; description=&quot;Tracing Provider Wrapper&quot; type=&quot;EFTracingProvider.EFTracingProviderFactory, EFTracingProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=def642f226e0e59b&quot; /&gt; &lt;add name=&quot;EF Generic Provider Wrapper&quot; invariant=&quot;EFProviderWrapper&quot; description=&quot;Generic Provider Wrapper&quot; type=&quot;EFProviderWrapperToolkit.EFProviderWrapperFactory, EFProviderWrapperToolkit, Version=1.0.0.0, Culture=neutral, PublicKeyToken=def642f226e0e59b&quot; /&gt; &lt;/DbProviderFactories&gt; &lt;/system.data&gt; Wybieramy sposób logowania. Ja wybrałem wypisywanie zapytań SQL na konsole (kod ten należy umieścić gdzieś na starcie aplikacji): EFTracingProviderConfiguration.LogToConsole = true; Po takiej konfiguracji wykonywane zapytania SQL będziemy mogli śledzić z poziomu Visual Studio w okienku Output. Dla metody GetHeroes przedstawionej wcześniej zostanie nam wyświetlone coś takiego: Jest to dokładnie to samo zapytanie, które widzieliśmy wcześniej w EF Profiler. Śledzenie wykonywanych zapytań SQL podczas działania aplikacji jest ważne. Pozwoli to nam na bieżąco monitorować w jaki sposób dane są wyciągane z bazy danych. W razie potrzeby będziemy mogli zmienić sposób ich pobierania na bardziej optymalny.

Featured Image
Oct 17, 2010 2 min read 6 comments

[PL] Entity Framework i wzorzec Repository

W tym poście przedstawię swoją implementację wzorca Repository z użyciem Entity Framework. Na początek zdefiniowałem interfejs IRepository: public interface IRepository where T : EntityObject { IQueryable All(); T SingleOrDefault(Expression&lt;Func&lt;T, bool&gt;&gt; predicate); void Add(T entity); void Delete(T entity); void Save(); } Następnie kolej na implementację klasy Repository: public class Repository : IRepository where T : EntityObject { #region private members private readonly ObjectContext context; #endregion #region constructors public Repository(ObjectContext context) { this.context = context; } #endregion #region public methods #region IRepository Members public IQueryable All() { return this.context.CreateQuery( this.context.MetadataWorkspace .GetEntitySetName(typeof(T).Name)); } public T SingleOrDefault(Expression&lt;Func&lt;T, bool&gt;&gt; predicate) { return this.All().Where(predicate).FirstOrDefault(); } public void Add(T entity) { this.context.AddObject(this.context.MetadataWorkspace .GetEntitySetName(typeof(T).Name), entity); } public void Delete(T entity) { this.context.DeleteObject(entity); } public void Save() { this.context.SaveChanges(); } #endregion #endregion } Zdefiniowałem też Extension Method dla klasy MetadataWorkspace, żeby być w stanie pobrać tzw. Entity Set Name: public static class MetadataWorkspaceExtensions { public static string GetEntitySetName(this MetadataWorkspace mdw, string entityName) { EntityContainer entityContainer = mdw.GetItems(DataSpace.CSpace).First(); EntitySetBase entitySet = entityContainer.BaseEntitySets.Where(e =&gt; e.ElementType.Name.Equals(entityName)) .FirstOrDefault(); return entitySet.Name; } } Przykładowe użycie stworzonej klasy może wyglądać np. w ten sposób: Hero hero = Hero.CreateHero(0, 0, 0, 0, &quot;Test hero name&quot;, 0); DotBeerEntities entities = new DotBeerEntities(); IRepository heroRepository = new Repository(entities); heroRepository.Add(hero); heroRepository.Save(); W tym tygodniu udało mi się przenieść dane z plików XML do bazy danych SQLite. W nadchodzącym tygodniu postaram się zmienić logikę DotBeer’a tak żeby używała Entity Framework.

Featured Image
Oct 16, 2010 2 min read 2 comments

[PL] Enity Framework Designer – StoreGeneratedPattern bug

W SQLite używam autoinkrementacji wartości kluczy głównych w tabelach. Domyślnie wygenerowany model przez generatora Entity Framework nie uwzględniał tego faktu. Próba wstawienia nowego rekordu do tabeli zakończy się po prostu błędem, ponieważ Entity Framework będzie chciał wstawić jakąś wartość. W celu naprawienia tej sytuacji musiałem w designerze ustawić pole StoreGeneratedPattern na Identity: Dzięki tej właściwość, EF zostawi wstawienie wartości kluczy głównych dla bazy danych. Wszystko byłoby pięknie gdyby nie pewien błąd. Designer EF w pliku EDMX ustawia wartość StoreGeneratedPattern tylko w sekcji CSDL, pomijając sekcję SSDL. Błąd jest znany i został zgłoszony blisko rok temu na Microsoft Connect. Do dzisiaj jednak nie pojawiła się żadna łatka do Visual Studio, która naprawiałaby ten błąd. Sekcję SSDL niestety trzeba poprawić ręcznie. W tym celu należy otworzyć plik EDMX w edytorze XML: Po otwarciu pliku w edytorze XML należy znaleźć odpowiedni fragment w sekcji SSDL i go poprawić. Rozwiązanie to ma jedną wadę. Wszystkie wprowadzone zmiany zostaną nadpisane jeśli zaktualizujemy model poprzez designera. Ponowne wprowadzanie poprawek do sekcji SSDL może być czasochłonne i zwyczajnie frustrujące przy dużej ilości encji. Co można, więc z  tym zrobić? Możemy np. zainstalować dodatek do Visual Studio Huagati DBML/EDMX Tools. Dodatek pozwala m.in. na wybór, które części pliku EDMX mają zostać zaktualizowane. Możemy również skorzystać z opcji synchronizacji pomiędzy częścią CSDL i SSDL. Narzędzie rozwiązuje, więc omawiany problem w tym poście. Tutaj znajduję się krótkie wprowadzenie do tego dodatku. Wszystko byłoby pięknie gdyby nie jeden problem. Dodatek jest płatny. Za wersję Professional należy zapłacić 149.95 USD. Może kiedyś się skuszę. Na razie zastosowałem inne rozwiązanie. Poprawną wersję pliku EDMX przechowuję w oddzielnym pliku jako kopię zapasową. Następnie po aktualizacji modelu używam WinMerge do porównania zawartości kopii zapasowej z aktualnym plikiem EDMX. Odnajduję interesujące mnie różnice w plikach i kopiuję dane z kopii zapasowej do nowego pliku EDMX. Rozwiązanie może nie jest super wygodne, ale na pewno jest lepsze od ponownego poprawiania pliku EDMX. Z WinMerge różnice w obu plikach widać jak na dłoni.

Featured Image
Oct 10, 2010 1 min read 1 comments

[PL] Vingy

Vingy jest dodatkiem do Visual Studio umożliwiającym wyszukiwanie informacji w Internecie z poziomu Visual Studio. Dodatek do naszej dyspozycji oddaje takie oto okienko: Całość jest banalna w obsłudze. Wpisujemy interesującą nas frazę i dostajemy wyniki. Po wyborze którejś pozycji z listy otworzona zostanie domyślna przeglądarka systemowa. Wyniki wyszukiwania możemy filtrować po kilku najbardziej popularnych serwisach programistycznych: Vingy na pierwszy rzut oka wydaje się ciekawym dodatkiem do Visual Studio. Jednak jeszcze zbyt krótko z niego korzystałem, żeby wypowiadać się na temat jego rzeczywistej przydatności. Pewnie następne parę dni zadecyduje o pozostawieniu lub skasowaniu dodatku.