Graphinder – Solution changes and nuget hell

While I’m moving my solution closer and close to first microservice part, I’ve decided to rearrange my solution a little.
I’ve decided to divide folder hierarchy inside solution, based on to which microservice part it belongs.
Besides a minor inconvenience on having to manually rearrange folders despite the fact that they were already in Visual Studio (solution folder does not represent physical one in system), I think it went quite smoothly. As long as I didn’t attempt to restore my projects’ depedendencies… and entering nuget hell.

Nuget hell genesis

I’ve decided to move all my algorithms project elements from solution root to subfolder of /Algorithms.
Of course, first thought: “there would be problem with packages path”. Nuget will have problem with finding ../packages folder as it’s located by default in solution root.
Alright, I’ll change paths in project files then. Example change that occurred in .csproj was:



Straightforward, right? Right.
But Visual Studio insisted that:

This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.

But by the love of… they ARE THERE. !#(*@#*(!^#*!^##&T*$@(#!@!
Alright, calm down. Let’s look for some clues then. Keep looking…
We have a suspicious thing here. Error tells us that the guilty one is \packages\xunit.runner.visualstudio.2.1.0\build.

Nuget hell – solution (a.k.a nuke em all)

What would a sane developer do? Delete reference perhaps. Let’s try out then.
Reference of xunit.runner.visualstudio.2.1.0 removed, rebuilding project, looking at build output…

This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.


But I’m not even referencing this, how come!?
Let’s see what’s in the project’s .csproj once again…
Wait a second fella, what are you still doing here?

Whole XML node removed, nuget readded from Package Manager Console, let’s see now what will explode…

========== Build: 11 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Now that’s what I’m talking about! New solution hierarchy feels a little more organized now, although I’m already thinking of splitting it into Shared, WorkerApi and GatewayApi subfolders for the sake of readability.

Final outcome of my crusade against nuget references:

nuget hell solution outcome

Graphinder – Encapsulating persistence layer

Recently we’ve been talking a little about difference between domain and persistence models.
The main reason I mentioned for using both is making our domain logic completely persistence agnostic.
But how do we actually tell another developer using our persistence layer API to go with an exact behavior we want?
Since database context, persistence models and ways of mapping are generally visible outside of the data access layer, I began to search for a solution to get rid of it.
This article will elaborate in short on encapsulating persistence (or data access) layer, so that only the things we want to be used from other layers are the things that are exposed.

Encapsulating database context

Let’s think of a simple DbContext that EntityFramework offers:

Wherever our data access project is referenced, AlgorithmContext is accessible. That’s a huge NO-NO!

So how about we make our AlgorithmContext internal?

But what internal keyword actually means? Let’s see:

The internal keyword is an access modifier for types and type members. Internal types or members are accessible only within files in the same assembly.

As we’ve already made our data access layer a separate project, it’s a separate assembly. Therefore, our context won’t be visible for other projects referencing it.
So far we’re good. First goal achieved: encapsulating persistence layer.
But still, we need to expose it somehow, so layers referencing our data access layer can actually, you know… access data. :)

Exposing data access

As stated in previous article, I’ve moved from repository pattern to queries and commands approach.
Let’s make a quick recall on how an example of query would look like. I’ll use simple example based on actual Graphinder code, as opposed to examples used in previous article to get closer to real world case:

As AlgorithmContext is already internal I can’t expose it outside assembly with public keyword, because that would cause an accessibility mismatch. That’s actually great, because whenever I’ll attempt to use my context around data access project, there is no way I will raise its accessibility above internal.


Query accessibility:

Context accesibility:

“Cannot access internal field ‘Context’ here”

Exactly what we wanted here! Cool!

But we want our API to be idiot-proof, don’t we?
No playing around with persistence models here. No knowledge on how anything is mapped, on how everything is persisted. Right?
Just make it all internal then. If we’re encapsulating persistence layer properly, only knowledge of very few things is exposed:

  • How to Query data from database
  • How to send Commands so that data is either created/modified or processed

No other functionality should be exposed here.

Wanna play around with my approach? Go visit GitHub then:

Last word of reminder

Such design is not reflection-proof. There is no such code. It’s also not idiot-proof if your fellow guys from team change signature from internal to public because it’s “easier”. Messier is always easier.

Graphinder – Queries and Commands vs Repository pattern

While planning a data access layer for Graphinder project I found myself really frustrated with Repository pattern, that I’ve followed for quite a time like a mantra, that was spread by many business and by Microsoft itself. But since Entity Framework 6 already provides a mix of repository and unit of work pattern, why would I build yet another abstraction over it?
That’s when I stumbled upon a concept of Queries and Commands, known especially from CQRS (Command and Query Responsibility Segregation). I would like to emphasize here, that I’m not 100% into CQRS. I like to think of myself as a picker of what’s best for me from any either newer or older pattern/approach. I’m nobodies blind follower.

What’s wrong with Repository pattern

Repository is a good-old pattern that is around here for some time already. Its purpose is quite simple:

The repository mediates between the data source layer and the business layers of the application. It queries the data source for the data, maps the data from the data source to a business entity, and persists changes in the business entity to the data source. A repository separates the business logic from the interactions with the underlying data source or Web service.

So we have mediating, we have mapping (post about persistence models: Domain models vs Persistence models) and we have seperation. And we do agree with those points, right? Right.
But things are not so simple out there. Repositories often end up as big, bloated almost-god-objects with lots of one-time-usage methods, spanning to mostly hundreds and hundreds of line. When we see such class in domain/business layer, what do we think first? Decomposition!

Why such thought have not been born here? Why encourage things like this (example exaggerated on purpose):

Of course we can go with query that takes one object of query params that will have milion of properties inside of it. And we can keep on going on this. But why?

Queries and Commands – decomposition

Why not go the other way round? When I see such big object with big responsibilities, I think decomposition.
I don’t care if it is most adore pattern in the world. From the moment I look at it, I can see how a great idea is so wrong much too often on implementation side. Why wouldn’t I go for something like this instead:

Can’t a simple insert operation be like this instead:

I know what would you ask now: how do I test then?
Question is, what would you like exactly to test here, except of maybe null or empty string or invalid debt value (which you can still test here)? Or maybe its ORM you want to test here? But let’s assume you really want to. What now?
You could simple create abstraction, ie. IUserContext instead of DbContext and expose it either through ctor or through public property. You can mock it now, you can stub it now.

So, how about replaceability here?
It has been said that it’s a common myth that databases are commonly swapped in business applications.
I would say that yes: it is quite rare. But it doesn’t stop you from being prepared!
In a rise of NoSQL solutions, it will also be much more easier to play around and test new technologies.
But hey, we already got it hidden from both domain and services layer, don’t we? Caller doesn’t care what is called up there. And that’s our goal.
As for replacing… Well, provided we don’t want to go through each query and command class to make an actual swap, we might want to expose Context up and just inject a property through any mainstream IoC container.
As an example, Autofac offers it out of the box:

Let’s sum it up then:
I guess I’ve just unsubscribed myself from Repository fan club.