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.

  • Naeem Sarfraz

    Interested in why you’re not using a dependency injection framework instead opting for Assembly.Load?

    • Both the PostgreSql dll and the SqlServer DLL implements the same repository interfaces. Hence they can’t both be loaded at the same time unless more complexity should be introduced.

      Therefore I use Assembly.Load to load the correct DLL and then register all services from that DLL in the IoC container.