Lately I have written a lot of posts about the Repository and Unit of work patterns. You can check out all the software design posts about why I think they are (still) useful and how you can use the Specification pattern to improve on it. So this pattern has been
In a previous post I described the specification pattern, its uses and benefits and also gave a pretty neat implementation. However, there was something that I didn't discuss: the variance aspect of the pattern. It is a very important aspect, but that post was long enough as it was — so
is a tricky interface. Some people argue that it is actually a bad abstraction, because it is impossible to implement it. This post is not about trying to prove or disprove this point. People who say this do have a point, but I do think they are wrong.
The age-old question of whether you should use the Repository and Unit of work patterns comes up pretty often in my life. That's probably because I'm for and not against :) and whenever I teach or wherever I go to consult, I always tell people to use this pattern. And then
So let's say you have your own DbContext descendant with a couple of DbSet
properties that contain your entities and you also want to configure some of your entities. If you know EF, you probably know how to do this (and why to do it like this). Here's an
In the past I created a number of custom solutions to generate the migration sql from Entity Framework Code First migrations (see my post here for soft delete automation, here for auditing migration automatically, here for specifying filtered indices and the one I created recently about adding an index to
I know that there are a lot of people out there who think design patterns are not useful or not important. You can learn them from any book or catalogue and then you simply add them to you code. While I try to be respectful of all opinions and definitely
Decorator is one of the most useful OO design patterns out there. It's basically a holy grail of helping you stay S.O.L.I.D.: it lets you keep the responsibilities to a minimum in a component, while also being probably one of the best examples of the open/
Dependency injection is awesome. I have written a lot of posts that start the same way; mostly because dependency injection is awesome. I'm not going into the details of why (I have already done that in those posts), let's just assume I'm right :) When using dependency injection, there is a
The repository and unit of work design patterns are useful. This is a statement that I can get behind in any debate when this topic comes up. Don't worry, I'm not dogmatic, I have a couple of really good arguments (IMHO) as to why. But I'm very tired of having
I regularly teach courses on basic object-oriented design patterns. Over the years I have come to realize that not every pattern is equally useful or equally well-thought out. One of the most common examples of patterns that have become more like anti-patterns over the years is the Singleton pattern. But
My speciality is backend, but sometimes I have to do frontend as well. I don't really like it, but I guess that's life. Sometimes I even have to do frontend with ancient technologies like WPF. Again, I guess that's life. So a colleague of mine came to me wanting to
Dependency injection is awesome. And Autofac is probably the best DI-container out there. It's like magic :) I really like to fiddle around with special registration concepts, like here, here or here. Or down below :) Keyed service registration and resolving Autofac has a great set of features called implicit relationship types.
Sometimes I do these posts where I describe an interesting question on SO. And sometimes I do posts about dependency injection and dependency injection containers. Well, this time, these two series cross-over (the Avengers of blog posts :) ). So Autofac has a number of nice features described as implicit relationship types.
Yes, you've read it right: in this post I will show you how to inject arguments to method calls and create something like a 'method call' scope. It's not perfect and there are a lot of things that still need to be considered more carefully, but I was really excited