Browsing posts in: Architecture



Running services in long lived applications in .NET

You have probably created a windows service or other types of applications where you have code which need to be run in the background to not block the main thread. To do that you have different types of solutions in .NET, for instance Threads, Timers and Tasks. However, you need to construct them manually, make sure that they do not throw unhandled exceptions etc.

Griffin.Framework provides a simpler solution where you only need to implement a small interface. The library also have full support for your favorite inversion of control container, which enables to to use dependency injection in your application services.

Continue Reading



Easy and perfomant client/server communication with protobuf-net & Griffin.Framework

ProtoBuf is Googles open serialization format which can be used to serialize objects in a standardized way. With it, different platforms can communicate with a format that is much more efficient than XML. Combine the most popular implementation if it, protobuf-net, with Griffin.Framework and you get an easy and fast way of sending information between processes.

Continue Reading



The danger of frameworks

I introduced Entity Framework (Code first) to my team in the beginning of this week. The other devs have not used it before, but as they are a Microsoft focused shop it was the only option other than ADO.NET. EF is a great tool but yet again I’ve got an example of how it blinds developers. It’s not just a Entity Framework problem, but frameworks in general.

The thing is that we have tables which represents our entities. Some of the tables are loosely coupled, but the EF Power Tools interpreted the relations as strong (thus interpreting some tables as junction tables). Most of the problems was sorted quickly by the dev. But one problem remained. And that was that cascading deletes did not work.

Instead of writing the delete queries manually the dev spent a day or two to fix the problem. I’m quite certain that a vanilla ADO.NET solution would have taken at most 30 minutes. What I’m saying is that ORMs works for most cases but not all. Unfortunately they blind developers. ORMs are so easy to use for the more common cases that the devs doesn’t seem to see that they waste hours on something that could have taken minutes with an alternative solution.

Use the right tool for the job.


Introducing the data mapper in Griffin.Framework

As you might know I’m running a .NET exception service called OneTrueError. When I moved from a NoSQL db to SQL Azure I had to be able to work with the database in some way. I’m not using OR/Ms any more. They might significantly reduce the bootstrapping, but in the long run they always tend to make you struggle as the application grow. To me, ORMs is a bit like ASP.NET WebForms, but for data. i.e. it tries to make something what it isn’t. I therefore wanted something that did not take away the control from me nor hide the underlying layer. I still want to work with my domain entities though.

Continue Reading



Pages:1234567