Dapper supports joins but not in the way you are used with Entity Framework. With little extra code, the entity looks very much like Entity Framework.
In unit or integration tests we often need to create input with data. For example if you test a mapper, all properties of the input must have a value. It will save time if most of the properties are filled in with values automatically.
These principles helped me a lot writing maintainable code: These principles are well known and easy to refer to when you do a code review. I still feel that I have to add one principle that is missing: descriptive names everywhere
Tiny types (also called micro types) can make code easier to read and navigate. Also validation can be done at a single place.
If you use this IMapper<,> interface for all mappings It is immediately clear from what type to what type it maps. On top of that we can now create extension methods working for all mappers supporting this interface.>
When you create a generic method (Foo
This blog describes how you can convert a string like "Alex" to a Guid with value: 1fe62611-cd3f-46e3-1e09-0ccb19e446e7. The same string always results in the same guid.
In an earlier post I compared the performance of Int (with autonumber) and a (Sequential) guid in SQL server. I posted an implementation of a C# SequentialGuid that created Guid's that were sequential, but they where still regular Guids. Once you had a Guid, it was just a regular Guid with the last 6 bytes ordered. The new version is a wrapper around the Guid with some cool extra stuff.
Elements of an IEnumerable sequence do not know about the other elements. I often need to compare an element with a previous or next element. Sometimes I need other context like all the other elements, the previous elements or if an element is the last element. That is why I use an extension method that adds context to all elements.
I saw many password generators but none of them did what I needed. Also it was often not random enough and/or unnesessary complex. So I created my own password generator. It has parameters for the lenght of the password, the minimum lowercase, uppercase, numbers and special characters.
Paging with Linq (to objects) seems quite simple: This is handy when you need a page 'in the middle only' but if you need to enumerate all pages, you have to caculate the number of pages yourself. The next method will help you to get all pages:
Command line parsing in C# is (static void Main(args string) is very limited. That is why I created a ParameterParser class that results a list of Parameter objects that can be queried with Linq. An example:
Lots of people uses naviagtion systems like TomTom these days. As a C# deveoper you might want to know what the basic principles are behind these systems. This post shows you 3 fully functional classes behind the principles of a navigation system.
Creating of unit tests of a method with 1 bool parameter needs at least 2 unit tests (false and true). But how many unit tests do you need for a parameter of type IEnumerable
A long story today, but very instructive if you do not have much experience with SOLID. I will give you 2 clues in advance:
Recently i had to choose a type for an Id in a SQL server Database. We are using Entity framework to access the database. I had to choose between Guid an Int. I seems to me that Guid must be a slow solution but in a real world scenario, this was not true (see results later in this blog). First an (optional) small introduction about some terms used here. Then the testresult , folowwing by the C# implementation of a third option, called Sequential Guid.
While designing a new programming language, I wondered if I would cache query results by default or not. Caching has advantages and disadvantages. I Found a solution that has the best of both worlds. The solution is also possible in C#!
Immaging that you have a customer that should pay you €10, €10, €20, €30, €30. He already paid you €10, €20. You need to know what he still needs to pay you. How will C#/LINQ helps you to give the answer?
Today I saw a Stackoverflow-post about a genaral solution for tree and nodes. It reminds me of a solution I created to store departments in tree. I was surprised that no standard .NET collection does exactly what I need, so I created my own Node
In a project I had to map a lot of external codes and values to our codes and values. This results in methods with switch statements:
In a collection we can easily check if there is any (particular) item: This is a very efficient way to check because it doesn't enumerate the whole collection. After enumerating the first element, the Any() method returns the result. This saves time if the collection is large or enumeration goes slow.
In a previous project we stored the values of an enum in a database. That made it easy to fill listboxes and comboboxes. It also helps to ensure data integrity. Storing enums means a violations of the most important rule for developers: single point of definition.