OJ Develops

This is the second post of my two-part series about designing applications using vertical slices and how the open-source library MediatR can facilitate this design. In the first post we talked about the vertical slices design and how it addresses some of the problems in traditional database table-centric designs. In this post we will see how we can implement a vertical slices design using the open source library MediatR. Put on your programmer hat as we'll dive into some code!

This is the first of my two-part series about designing applications using vertical slices and how the open-source library MediatR can facilitate this design. In this post we will talk about the concept of vertical slices and in the next post we will look at some sample code that implements this design.

The second part of this series is now out: Vertical Slices Application Design with MediatR: Part 2

Today we are going to take a look at libraries and frameworks. We will describe each of them and take a look at some examples for each. We will also take a look at a practical example of how being able to distinguish between the two will help us in our daily coding.

Let's talk about a simple but important topic: why use viewmodels in our web applications. Specifically, the kind of viewmodels that we will be talking about are the ones that are used as parameters or return values in controllers.

In the last post I gave an introduction to dependency injection, where I described what it is, how it can be achieved, and the motivation behind it. We left off by providing an example in an ASP.NET MVC controller, where we manually "newed up" dependencies inside the constructor of a controller. In this post we will take a look at dependency injection frameworks and see how they can help us manage dependencies.

The concept of dependency injection has been around for a long time. But now that dependency injection is baked into ASP.NET Core 1.0, I thought it would be a good time to write about what it is and why and how we can take advantage of it.

This post is part 1 of a two-part series on dependency injection. Click here to go to part two.

Today I'm going to talk about a slightly controversial topic about using the repository pattern in combination with an ORM such as Entity Framework.

In a previous post I talked about how we can manage lookup tables with Entity Framework Code First. In that post I suggested using the primary key directly to check for a specific lookup, rather than introducing an arbitrary column that will serve as an identifier. In this post I will talk about how we can make a generic lookup service to simplify how we show lookup values in, say, dropdown lists.

SQL Server lets us design tables which have constraints and checks in them. Some examples of these constraints / checks are primary key constraints, nullability flags, maximum length flags, and so on. These checks are used to ensure data integrity. Insert, update, and delete commands which will result in an invalid state when executed are not allowed. However, there are some advantages to not using these checks. In this post, we will talk about some of those advantages.

In this post we are going to show a simple example of refactoring code to better adhere to the Single Responsibility Principle (SRP).

Business rules can be mixed into data access code. This scenario is a violation of the Single Responsibility Principle, because the data access class would have to change if the business rules change. In this post I will show you how to separate the business rules from the data access code.

My opinion on using web services that are not consumed by external clients is this: they should not be used.