Architecture/Design/Patterns

Dependency Injection (DI) was also supported by classic ASP.NET MVC but there was no framework-level dependency injection like in ASP.NET Core. In this blog post I will show how to use Structuremap for dependency injection in ASP.NET MVC applications and how to resolve dependencies using built-in components in classes that doesn’t support dependency injection.

My last bold statement was that we don’t need custom unit of work and repository classes with Entity Framework Core. One issue remained unsolved and it was querying part of repositories (yeah, those custom querying methods). After some experiments to get querying interface of repositories to DbContext I worked out something that I kind of like. I managed to make DbContext to work like classic unit of work that hosts repository instances. Here’s my experiment and the solution I worked out.

Surface Neo and Surface Duo are new devices by Microsoft, planned to launch for holidays season this year. Surface Neo runs Windows and Surface Duo is based on Android. For Surface Duo there’s already preview tooling and SDK available by Microsoft. Here’s the introduction to Surface Duo development, tools and patterns.

My previous posts about tenant-based dependency injection and using composite command in ASP.NET Core culminated with idea to use configurable composite commands in multi-tenant ASP.NET Core applications. Configurable composite commands make it easy to tweak save and update processes that contain multiple steps of what some can be custom and their activation is based on tenant configuration. Here’s how to build thost composite commands.

One need in multitenant applications is injecting dependencies based on tenant configuration. It can be actually more complex as instances may need constructor parameters. Here is my example of dynamic injection of multiple file clients in ASP.NET Core multi-tenant web application.

Modeling employees seems to be easy when we get started but it quickly turns more complex than we first expect. Specially if we need good and flexible model we don’t have to replace time by time. This post is continuation to my writing Modeling people and organizations: Party generalization and it extends the previous model with support to employees.

After my first experiments with Query Specification pattern on Entity Framework Core I came to interesting idea – why not using extension methods that wrap query specifications or add directly some more conditions to IQueryable the way that queries are easy to read. Here’s my experiment and thoughts of fluent readable queries.

My previous blog post No need for repositories and unit of work with Entity Framework Core showed how Repository and Unit of Work patterns are already implemented in Entity Framework Code (and NHibernate) and how we can use IDataContext generalization to get ORM-s behind same interface. As I’m still trying to find out what’s the best place where to isolate queries without exposing IQueryable I started playing with Query Specification pattern.

After working again on codebase where Entity Framework Core was used through repository and unit of work patterns I decided to write eye-opener post for next (and maybe even current and previous) generations about what Entity Framework has to offer in the light of these to patterns. In many cases we don’t have to move away from database context approach but stick with it even more than we first planned. Here’s how many useless repositories and units of work born and here’s also how to avoid these and go with implementations offered by Entity Framework Core.

My introduction to composite command pattern was more theoretical and focused to high-level details. This blog post focuses on implementation details and introduces how to use composite command in ASP.NET Core to upload and process photos.