Poprzedni wpis nt. biblioteki Dapper był tylko małą zachętą do sprawdzenia tej biblioteki, przetestowania jej i sposobu jej integracji w Twoim kodziku. Tutaj poruszę temat trochę szerzej, z punktu widzenia kategorii ORMów. Kodziku nie będzie 😉

Założę, że programujesz obiektowo. W takim razie niemalże na pewno zdarzyło Ci się stanąć przed wyborem bibliotek w momencie tworzenia rozwiązania lub przeglądać stos technologiczny istniejącego projektu. Myślę, że się nie pomylę, jeżeli napiszę, że w większości, jeśli nie we wszystkich przypadkach przed Twoimi oczami mignął jakiś ORM. Czasem okazuje się też, że SQL jest wymagany tylko i wyłącznie dlatego, że ten konkretny maper stoi nad tą, a nie inną technologią bazodanową.

Persystencja zawsze budzi wiele emocji i skrajnych opinii. W tym artykule pokażemy, jakie opcje są do wyboru przy persystowaniu agregatów z DDD i jak pragmatycznie do nich podejść. Przejdziemy kolejno przez bezpośredni zapis agregatów, robienie Snapshotów, tworzenie osobnego modelu danych na podstawie zdarzeń, a na koniec dotrzemy do Event Sourcingu.

Entity Framework (and other ORMs) are in general great pieces of software that makes developers lives so much easier by letting us thinking about objects when we’re working with data persisted in some underlying database. This makes development much easier than writing raw SQL queries. But some of us tend to get too comfy and forgetting about things that lies beneath our beautiful, object oriented code. After all we have Entity Framework, we shouldn’t wrap our heads around SQL stuff. But how about actual...

Every programmer when working with databases will use a framework, which facilitates and speeds up development time. It is no different with me. I never liked ADO.NET. Taking out the data and storing it in a DataSet or DataTable that were not strongly typed is not a best idea. Especially when someone else on the later stage had to work with this code and no one actually knows what the author had in the mind writing it. For many years, I enjoyed the heavi...

Let's assume that we have a simple table GL_Task which looks like this I was asked to rewrite simple SQL query SELECT Id,Name,IdProject FROM GL_Task WHERE Name = 'First task' OR Id IN (3,4 /more id's to come/) using NHibernate's QueryOver API. As simple as it may seem, solution for this particular problem is not straightforward. My first (not so clever) attempt was simply combining WhereRestrictionOn and Where clause var result = session.QueryOver

Entity Framework, has given with last update, migrations at code first, undoubtedly it’s the best feature in this update. This tool is very helpful if we change something at our model, and then we can simply upgrade our database. Moreover it can fulfill role as a database versioning, because we can easily to manage our updates and freely manage between them.

Światy: obiektowy i relacyjny nie pasują do siebie. Dlatego tak popularne są mappery obiektowo-relacyjne, dzięki którym życie staje się łatwiejsze. Ale jaki mapper wybrać?

To ostatni, przynajmniej na razie post o NHibernate. Jest on podsumowaniem wszystkich moich wysiłków w kierunku poznania podstaw tego ORMa.  Wcześniejsze etapy prac przedstawiłem w postach o mapowaniach NHibernate'a oraz zarządzaniu sesjami. Zmiany w klasie SessionManager W porównaniu do klasy przedstawionej w poprzednim poście musiałem wprowadzić niewielkie zmiany. Zdecydowałem się jednak zrobić ją klasą statyczną oraz przeniosłem funkcję MakeTransaction do głównej klasy dostępu do danych, oto jej a...

LLBLGen Pro – płatny O/R Mapper. Czy warto?A cóż to i dlaczegóż to Niedawno Szymon napisał posta o O/R Mapperach. Korzystając z impulsu postanowiłem także popełnić co nieco w tym temacie, tym bardziej że tą konkretną notkę zaplanowałem przynajmniej 2 miesiące temu. Może ona być uzupełnieniem dla projektów wspomnianych przez Szymona, czyli NHibernate, Linq2Sql i Entity Framework.