Using a SynchronizationContext in unit tests

We’ve started to use the Progress<T> class in our async application. However our tests started to fail because of that (when validating that our callbacks get invoked). This post will show you how to create a simple SynchronizationContext to make sure that everything is invoked before the assert part is being run.

Continue Reading





Griffin.Yo – Easy SPA library written in TypeScript

All SPA libraries that I’ve tried have long tutorials to show you have to use and configure them. It’s not unusual that they allow you to structure your application just as you like, which might be great for powerful users, but make it more confusing for newcomers. Here is an introduction to my own library which should be reasonable easy to get started with.

Continue Reading



The quest to generate the perfect repository – Griffin DAL Generator

The data layer is something really important in an application. If it’s incorrectly created it will behave like a virus and infect the entire business layer making it a lot harder to build and maintain the application. Unfortunately the symptoms will not appear until the project have been built for some time. In this article I’ll present my attempt to a cure.

Continue Reading


Sample repository using Griffin.Framework

Here is small sample repository using Griffin.Framework

using Griffin.Container;
using Griffin.Data.Mapper;
using OneTrueError.GlobalCore.Invitations;
using OneTrueError.GlobalCore.Invitations.Data;

namespace OneTrueError.GlobalCore.SqlServer
{
    [Component]
    internal class InvitationRepository : IInvitationRepository
    {
        private readonly GlobalUnitOfWork _unitOfWork;

        public InvitationRepository(GlobalUnitOfWork unitOfWork)
        {
            _unitOfWork = unitOfWork;
        }

        public Invitation FindByEmail(string email)
        {
            return _unitOfWork.FirstOrDefault<Invitation>(new {EmailToInvitedUser = email});
        }

        public void Create(Invitation invitation)
        {
            _unitOfWork.Insert(invitation);
        }

        public void Update(Invitation invitation)
        {
            _unitOfWork.Update(invitation);
        }
    }
}

As you might have noticed I’m using one Assembly/DLL per SQL engine that we support. It’s not required for Griffin.Framework, but we are using plain ADO.NET for some DB operations and Griffin.Framework for others. Thus having one DLL per SQL engine allows us to write optimized queries without compromises.

In v2 of OneTrueError we are using two different databases. One for global activities like billing and customer accounts and then one customer specific DB for each customer. The reason is that we’ve had customers which gets several GB of error reports each month. Thus to make sure that the DB is responsive for all other customers (even when we are lacking a few efficient indexes) we’ve taken this approach.

When OneTrueError is started we simply use Assembly.Load together with a configuration setting in <appConfig> to be able to load the correct DLLs.


Pages:1234567...16