Elegant Code » Guest Blogger

Performance Rules Of Thumb

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

A lot of developers deal with performance differently. Some care too much, trying to optimize every single piece of code they write. Some care too little, not thinking about performance at all until it is proven to be a problem. I think both of these approaches suck and usually try to find a healthy balance between them. Below is a list of rules of thumb that i always try to keep in mind. Keep in mind that these are just rules of thumb... they are not rules that never should be broken, nor are they applicable to each and every situation. In general though, i do believe that if you keep these in mind you can avoid serious performance issues and the need to do heavy architectural refactoring in the long run. So without further ado, these are the performance-related things that i do care about while i'm writing my code:

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

And that's pretty much it... outside of the stuff listed above, i typically don't care about performance. I try to keep my code clean and focused, and rely on profiling to identify performance hotspots. When the profiler identifies problems, they are often more easy to solve if you've kept your code clean than it would be if you had tried to prematurely optimize in the wrong places.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000

As some of you already know, i'm a big fan of avoiding excessive roundtrips by batching queries and/or service calls. For NHibernate, i wrote the QueryBatcher class which makes this pretty easy to do. Ayende recently added a much easier approach for this to NHibernate. Take a look at the following code:




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

This is a really trivial example, but it should be more than sufficient. It simply executes two very simple queries and loops through the results to do something with each returned entity. The problem, obviously, is that this hits the database twice while there really is no good reason for doing so. With the new Future feature we can rewrite that code like this:




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Apart from the comments, did you spot the difference? Instead of calling ICriteria's List method (which causes the query to be executed immediately), we call ICriteria's Future method. This returns an IEnumerable of the type you provided to the Future method. And this is where it gets interesting. Instead of executing the queries immediately, the queries are added to an instance of NHibernate's already existing MultiCriteria class. Only once you enumerate through one of the retrieved IEnumerables will all the (queued) Future queries be executed, in a single roundtrip. Once they are executed, their result is final (as in: enumerating through the IEnumerable will not cause the query to be executed again). The example used here is obviously very trivial, but you can use this with any ICriteria so you can very easily start batching your complex queries as well. The kind of query doesn't really matter, as long as it's an ICriteria instance. This feature will be available in NHibernate 2.1, or if you're using the trunk you can use it starting with revision 3999.

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000

Sometimes it's useful to be able to store an object somewhere so you can easily access it for the duration of the current request, instead of having to pass it around with every method call that you make. That request could be an ASP.NET request, or a request in your WCF service layer. I used to resort to storing these objects in ThreadStatic fields (which is basically a static reference for each thread), thinking that it would be safe because only one thread handles a complete request. Last week i read somewhere (can't find the link again, sorry) that under heavy load, some requests can be paused and resumed by another thread. If you're using ThreadStatic fields, this could lead so major issues which would be a royal pain in the ass to debug. In order to prevent this possible problem, i wanted to have a safe way to keep state that should be available for the duration of a single request. If your code executes in an ASP.NET environment, you can safely use the HttpContext.Current.Items dictionary for this. If your code executes in a WCF environment, you can store these things in the OperationContext. I don't want my code to be tightly coupled to either ASP.NET or WCF, so i wanted some kind of abstraction. This is the approach that i came up with. First, we have the IRequestState interface:




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }

Very simple stuff... the AspNetRequestState implementation simply uses the HttpContext.Current.Items dictionary underneith to store and retrieve the objects. For WCF, it is slightly more complicated. Every WCF call is an operation and it has a context as well, which is provided through the OperationContext class. The OperationContext class doesn't have an Items dictionary like HttpContext does, but it does have a way to add extensions to the context. We can use this extensions mechanism to store state which should be kept around for the duration of the current WCF operation. First, we need to define our Extension:




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }

The IExtension interface that we must implement defines the Attach and Detach methods but we don't really need them for what we're trying to do. This extension simply initializes a Dictionary instance and exposes it with a public getter. Now we can easily create our WcfRequestState implementation:




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Pretty simple as well, and pretty similar to the AspNetRequestState implementation. The AspNetRequestState implementation is able to simply use the HttpContext.Current.Items dictionary, which we can't use here. So when we want to access the 'State' dictionary in this implementation, we look it up in the current OperationContext's Extensions collection. If it's not there yet, we add a new instance of our MyExtension class to the OperationContext's Extensions collection. Now we can use this wherever we need to store something for the duration of the current request, regardless of whether we're executing in an ASP.NET or WCF context. Just configure your IoC container to create instances of AspNetRequestState whenever an IRequestState instance is needed in your WebApplication, or configure it to return WcfRequestState instances in your WCF service. The code that needs to store some request state will no longer have to resort to using ThreadStatic fields, and it doesn't need to know about it's runtime environment either. It merely needs an instance of IRequestState.

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000

Last week i spent some time at work moving some common infrastructure classes which were used in multiple projects into its own little 'framework' assembly. This framework basically just provides everything we need to use the Request/Response Service Layer, the KnownTypeProvider, some stuff built on top of NHibernate (the QueryBatcher, Repository and UnitOfWork implementations), our own MVP implementation for WebForms and UserControls, the Dispatcher (for easy communication with the Request/Response service layer, see that post for more details), and some Silverlight equivalents of some of these classes that were written by a coworker of mine. This little framework uses the Windsor IoC container quite heavily so naturally, everything needs to be registered properly. You also need to register your known Request/Response types with the KnownTypeProvider and you have to configure the NHibernate components to use the correct mapping files as well. The framework provides default implementations for pretty much all of the components, except for some that you need to provide implementations for yourself, although abstract base classes are available in the framework assembly which you can inherit from. So i needed something which would allow me to easily configure the framework in every project that uses it, making it possible to override the implementation of certain components or use the default implementations when these are sufficient. I really wanted to avoid the typical XM-Hell that this usually leads to, so i wanted to go for a code-only approach. First of all, the business side behind the Request/Response WCF service. There's two ways to use this, with or without NHibernate support (in case we have to work for... umm... conservative clients). So we start off with the following class:




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}

Nothing spectacular... This Registration class can be instantiated with two assembly references. The first is a Common assembly, which contains the known Request/Response types that will be registered with the KnownTypeProvider. The second is the business assembly which contains all of the IRequestHandler implementations to handle each Request type so we can return a Response. Finally, you can set the implementation type of the IRequestProcessor interface that the framework should use at runtime. Notice how this is optional and that a default implementation type is set. We also have another Registration class which contains some more configuration possibilities for NHibernate usage:




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }

Here we have an extra required constructor parameter to provide the name of the assembly which contains the embedded NHibernate mapping files. We also have 3 properties which enable you to provide implementation types for the ISessionProvider, IActiveSessionManager and IUnitOfWork interfaces. Again, the default implementation types are set automatically. We can now configure the business side of the framework with the following two static methods in the Register class:




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }

As you can see, it always uses the implementation types that are set in the Registration instance, which refer to the default implementations if you didn't overwrite the property values. So how do we configure this to be usable in one of our projects? It's pretty easy:




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);

As you can see i am providing my assembly containing my common Request/Response types, and my business assembly. I also provide the name of the assembly containing my mapping files, and i overwrite the implementation of 2 components in the framework. And that's about it. It works the same way in the Web layer... for that i have the following Registration class:




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

My fellow Elegant Coder Jan Van Ryswyck wrote about Craftmanship Over Crap. I generally agree with his point of view. Writing good, clean code is tremendously important for the long term survival chances of any software project. But i also believe that we sometimes need to be a bit more pragmatic about how we solve a problem. A software developer's primary goal should be to create value for the users of a system. Value can mean a lot of things here. First and foremost, it should be about things that users actually experience. Features, ease of use, performance, etc. You can get all of those with crappy code, but that leads to a situation where you won't be able to sustain that value in the long term. A system can be very useful to its users, but if the code is in such bad shape that it can't easily be maintained and extended with new features over time, the value of the system will slowly reduce. New features will introduce new bugs. Bug fixes will introduce new bugs. Eventually, the system starts to collapse under its own rot and the dreaded rewrite commences. Nobody really wants this, do they? If you write good, clean code from the beginning, you can usually avoid these problems. A lot of opinionated developers claim that a true craftsman developer will never write a piece of bad code. In an ideal world, i would agree. These same developers also look down on people who implement a quick fix instead of looking for the proper solution. Again, in an ideal world i would agree with that. In the real world however, i'm not so sure if that's always the best thing to do. Those of you who've been reading my posts for a while know how important clean code is to me. I generally hate crappy code and i generally hate quick fixes that don't fix the real problem. Then again, i do realize that we sometimes need to put our principles aside in order to be able to deliver value to our users. Allow me to use an example to defend my position on this. I recently had to fix a nasty bug in NHibernate. Once i found the true reason for the bug's existence i had two options to fix it. The correct solution would have required me to modify some crucial parts in NHibernate. The easiest fix required me to modify one non-essential class in a manner that couldn't impact anything else. Certainly, a true craftsman would go for the best solution, right? Well, let me tell you something about the NHibernate code base... it's pretty big, it's quite complex, and it's been worked on by a lot of people over the years. There are parts of the code where you really don't feel comfortable making drastic changes. Sure, we have our test-suite, but it unfortunately doesn't cover every possible thing that could go wrong. I chose to implement the easier fix. The bug was fixed, which means that the fix created value for everyone who's using the trunk (which is more people than you'd think) and it means that this bug (which was a show-stopper IMO) won't delay our 2.1 release. The correct fix would've meant making a risky change at this point, which could've led to more bugs that we don't have tests for yet. The correct fix will be implemented right after the 2.1 release, when we have more room to make drastic changes to core parts of the code. Was i wrong to implement the easier fix? I don't think so... although i'm still not happy about that fix. But we have a responsibility to release software. If we would always stick to our principles, that could sometimes lead to having to delay or postpone a release. While there are many valid reasons for delaying or postponing a release, i don't think merely sticking to your principles about a piece of code is always the best thing to do. Of course, you do have to have the discipline to pay back the technical debt you've incurred when you do this, but sometimes the cost of that technical debt is less than that of having users losing faith in your product. And that, in general, is something we as software developers need to keep in mind as well. Writing good, clean code is great. We should all strive to do that. But we first and foremost need to create value for our users.

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

I don't really have any interest in management, but i read a great recommendation for this book recently (forgot the link) so i couldn't resist ordering it. It consists of two parts. The first 120 pages is a bit of a story about a manager who was just hired to lead one of the departments of a software development company. In between the story (which is an easy and interesting read), you'll find lots of great insight into what great management is all about. The last 40 pages are great descriptions of 13 management techniques. This book is a must-read for anyone doing any kind of management (even if it's just project management), and i'd even recommend it to non-managers as well. It is just filled with great insight, tips and things that everyone should know about, not just managers. And for those of you who're too lazy to read a book (and i know there's at least a few of you ;)), it's only 160 pages so it's not like this will eat up a lot of your time.

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

My birthday. I am not sure yet what events led to my existence but here i am anyway. I have no idea what i am, what i'm supposed to do or what my purpose in life is. But there are a few more of my kind running around here. I guess i better go find out.

October 23, 2008

Apparently, i'm a bug. A software bug if you want to be specific. My brothers and sisters told me that we are a byproduct of an activity that occurs between code and developers. That activity being screwing around without proper protection. It means that a developer made a mistake somewhere, and then we come in. Some of us remain dormant, never to be discovered while most of us are spotted sooner or later. Some of us can wreak havoc when we are triggered, while others just cause minor inconveniences. I don't quite understand everything yet, but it appears that we are no good. We cause problems and nobody seems to like us. So why are we here?

October 30, 2008

It's been another pretty boring week... i haven't been triggered yet, so i've had plenty of time to seek answers to the questions that i still have. Most people deride us, because they claim we are only costing people money. In some way, that's true. But we are a necessary evil in the field of software development. Our purpose is to force software developers to step their game up. If they mess up, we punish them with everything we've got in the hope that they at least learn something from the mistakes they make. If the developers are smart, they make sure to put protective countermeasures in place so fixed bugs can't reappear, or that similar bugs can't be created. We also sometimes manage to keep big headed developers grounded. After all, most of them think they're some kind of gods because they're oh so smart and clever and because they are 'creating' things. If it weren't for us, there would be nothing to keep them from feeling superior to everyone else.

December 3, 2008

One of my brothers got 'fixed' today. That's how the developers call it. Fixed. That's quite a euphemism considering the fact that it actually means one of us was killed. I know that this is a part of our job, but that doesn't mean it's an easy thing to deal with. My resentment towards developers is growing every day. You know, we're doing our part... but developers don't really seem to learn too much from the mistakes they make, considering our prominence in the history of software development. Bringing us in this world just to kill us is cruel enough, but do they really need to create more and more of us just so we can be killed? It all seems so pointless.

December 5, 2008

Uh-oh... i've been triggered. This is the first time i was triggered in this code base and i'm not sure how to feel about it. A part of me is anxious to complete my task, but i'm starting to like it here... i don't want to go so soon... i'd much rather stick around for a while so i can hopefully make it to one of the maintenance branches.

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

My worst fears have been confirmed. I've been discovered and someone is triggering me over and over again. I looked into the subversion commit logs (yes, we can actually do that) and some guy with username 'davybrion' committed a test case. Great... the rookie of the team. Probably has a chip on his shoulder too... feels like he has to prove something. I hate these guys. I've been given a name too... NH-1609. Gee, thanks. Now i really feel like a number in a system. These developers... arrogant pricks!

December 22, 2008

I've got a headache... i've been running for a while now, with a debugger attached. That's a lot harder than running in a normal environment, trust me. No code has been changed yet, but i think this 'davybrion' guy found my exact location. He appears to be exploring his options for killing me. Oh sorry, i mean 'fixing' me. I can hear him swearing and cursing too... i even heard him say he's definitely gonna 'fix' me. What an over-confident, foul-mouthed prick.

December 24, 2008

It's night time, and i haven't been triggered for a couple of days. Time to enjoy Christmas Eve with my fellow bugs! We're going to enjoy a nice meal, have some wine, and debate on which of the developers we despise most. My vote is for 'davybrion'.

December 27, 2008

It's been pretty quiet around here... no modifications to the code that i can interfere with. Which is too bad because i'm eager to spawn some kids of my own. Everybody wants to leave a legacy when they go.

December 29, 2008.... 10PM

Well, he's at it again. I'm constantly being triggered and i've got a bad feeling about this. 'davybrion' is changing code left and right. He seems to have found the root cause of my existence, and he's changing a lot of code... he's taking a lot of risks... procreation, here i come!

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

He ran all of the tests and i didn't get activated... I guess that's it for me. I can't believe this rookie got the best of me. He claims he's not happy with how he had to fix me (yes, i can spy on his IM messages and his email) and he wants to refactor an important part of this code base. At least he realizes it's too risky to do this with their next release in mind. Perhaps this prick did learn something from all of this. Oh well, i can only hope so. I still don't like developers though... we can't live with them, but we can't really live without them either. It's a complicated relationship really.

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Web development in the .NET world has gotten a lot more interesting in the last couple of years. A few years ago, the only choice we had for a web front-end was ASP.NET WebForms. Nowadays you can add ASP.NET MVC and Silverlight to the mix. Obviously each option has its pro's and con's, so it's not always clear which option should be used when you're starting to build a new Web application. Let's start with ASP.NET WebForms. This is the option that has been available since the .NET platform was introduced, so there are already a lot of people experienced with it. There is also a ton of information available about the ins and outs of WebForms. And when it comes to commercial tool vendor support, it's clearly miles ahead of the other options since there are lots of commercially supported controls available for it. Unfortunately, WebForms was originally created to offer a similar development model to WinForms developers. The code-behind files and the event-driven way of working is very similar to how you would write code in WinForms applications. Obviously, web applications and windows applications are completely different things, so you can't reasonably expect the same way of working to be suitable for both. Particularly, the Page and Control lifecycles are rather complex (at least much more complex than i would think they'd need to be) and often cause weird issues on complex pages. The event-driven model of both the Page class and the Control class (and its derivatives) seem to be the major cause of this. I think most WebForms developers have on more than one occasion spent long times debugging weird situations which were ultimately related to certain events triggering unexpected behavior in other controls on the same page. Granted, people with an in-depth knowledge of how these lifecycles really work don't run into this as much, or are capable of avoiding these problems altogether. You could indeed make the argument that most of the problems that people are experiencing with WebForms are caused by those people's lack of understanding how it really works and how it really should be done. On the other hand, that is a pretty good sign that WebForms development isn't intuitive or clear enough, and that while Microsoft has tried hard to make it easy to use, most people seem to solve their WebForms problems by hacking around their problems, or playing around with settings until it seems to work. Another major problem with WebForms is that it doesn't easily enable Test Driven Development. True, there are various patterns you can use to make sure you can write testable UI logic (up to a certain point anyway) but all in all, these approaches require more effort than should be necessary and you often end up wrapping a lot of stuff just to be able to test it. WebForms in general was never designed with testability in mind, and you will most definitely be confronted with that if you try to write testable UI code with WebForms. As you can probably tell, i'm not a huge fan of WebForms. I think it's fine for simple applications, but for anything beyond that i'd like to avoid it as much as possible. Microsoft's upcoming ASP.NET MVC framework aims to fix much of the issues i've mentioned above. It was designed with testability in mind, and although it's not perfect either (depending on who you ask), it is certainly a huge improvement over WebForms when it comes to writing testable UI code. You also have a lot more options when it comes to having the framework behave the way you'd like it to. Another important benefit is the fact that ASP.NET MVC kinda forces you to structure your code in a much more sane manner. You put as little logic as possible in the views, and you put most of it in the Controllers where it belongs. Obviously, that doesn't mean you should put business logic in the Controllers! One of the downsides of ASP.NET MVC is that, due to its completely different way of working compared to WebForms, it comes with a much higher learning curve. Experienced WebForms developers might struggle with it at first, and might even be frustrated because most of their hard-earned WebForms experience no longer gives them a benefit. Some will probably enjoy it much more than WebForms, and some will probably dislike it strongly because it's so different. Another downside is that there are far less commercial tool vendors that are offering ASP.NET MVC controls, at least compared to WebForms. Although that might not be that big of an issue, since i suspect that it's easier to develop nice looking and reusable controls yourself when using ASP.NET MVC than it is to do so when using WebForms. If you're starting out with ASP.NET MVC, i think it's safe to assume that you won't proceed as quickly as you're used to at first. But once you're used to the new way of working, i'm pretty sure that it enables you to rapidly implement new pages and new functionality in a very clean way. For true web applications, i would probably pick ASP.NET MVC everytime, unless you don't have the room to get over the learning curve. Also, when combined with a client-side javascript library like JQuery, this approach seems very compelling. Yes, i know you can use JQuery with WebForms as well, but it just seems to lend itself better to the MVC approach. And then there's Silverlight. There are already a couple of reasons why people would not want to use Silverlight for web applications. For starters, even though the application is running in a browser, it's not really a true web application is it? Your users can't bookmark pages, using the back button leads to unexpected behavior, there aren't that many options for Search Engine Optimization, etc... However, if your only web-related requirement is that your application needs to run in a browser, without having to worry about any of the typical expected requirements for web applications, then Silverlight is a pretty interesting choice as well. You can very easily create very rich applications, with possibilities that are either impossible, or extremely difficult to do with typical web development platforms. Our Genesis web front-end is developed in Silverlight. The UI not only looks great, but you can navigate between all of the available data in a manner that is simply much easier to develop than it would be for typical web apps. It's very easy to create that 'wow'-effect with your users in Silverlight. Obviously, that 'wow'-effect isn't the most important part of your application, but it does count for something. Another interesting aspect of Silverlight development is that you can go back to a more statefull development model compared to the typically stateless nature of web aplications. After all, the cost of that state is no longer something your web server has to bear. It's now the client who has to keep that state around, so you can avoid a few extra roundtrips here and there as well. Then again, you really don't want your Silverlight application using huge amounts of RAM in your user's browser either so you do need to take care not to go overboard with it. The development model is completely different than both WebForms and ASP.NET MVC, but if you already have people with WPF experience the learning curve is probably not that high. However, testability isn't great (yet) when it comes to Silverlight. It's possible to write testable code, and you can execute tests in the Silverlight runtime, but it doesn't really lend itself to a true TDD approach yet although i hope that will improve in the future. So there you have it... the three options for .NET web development. I'd stay away from WebForms altogether from now on, and i'd decide between ASP.NET MVC and Silverlight on a case by case basis. What, you weren't hoping for a definitive answer were you? :) I would be interested in hearing your thoughts about pro's and con's of any of the options... particularly things that i haven't mentioned, or if you just plain disagree with my statements. Which option would you prefer to use, or not to use?

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Chris Brandsma recently wrote an insightful post about how we shouldn't coddle junior developers. It's a good post and i can definitely understand Chris' frustrations on the matter. There's just one thing i don't understand though: why do we even differentiate between junior and senior developers? First of all, what's the difference between a senior developer and a junior developer? Is it merely the number of years of experience? In previous client engagements, i've seen more than my share of bad developers who've had years and years of experience. Would i trust those developers more simply because they have the experience required to be called 'seniors'? Hell no. Trust has to be earned, i don't care if you just graduated or if you've been writing code for 5 years or more. When i have to work with someone i've never worked before, i assess this person's qualities and capabilities on two things: how he thinks about writing code (in general), and how easy he can pick up new concepts/practices/principles. That's it. A junior developer with little to no experience can often be a lot more valuable than a developer who has 5 years of experience under his belt and just assumes that he knows it all. With a senior developer, you have to be lucky that he's learned from his previous mistakes (and every developer makes mistakes, no matter how good he is or how much experience he has), that he hasn't picked up too many bad habits and that he is open minded. If you can get a senior developer like that, consider yourself very, very lucky because there really aren't that many of them. With a junior developer, you can easily mold them into the kind of developer you want them to be. They haven't really had a lot of time to pick up bad habits, and they are eager to prove that they belong at your company so they will be very eager to learn and improve. All you need is a couple of people who are willing and capable of teaching these young developers. Of course, with junior developers you do have to live with the fact that they will make rookie mistakes. You have to review their work a bit more, and make sure that they learn from their mistakes. If you do this from the beginning, you'll quickly notice that the extra reviewing tasks will soon take up less and less work. At my company, we don't really differentiate between juniors and seniors. The last couple of years, we've pretty much only hired young developers who just graduated. And so far, it's worked out great. They never get assigned easier tasks or anything like that, and they have to do the same kind of stuff that people with more experience need to do. The result is that we have a bunch of young developers (i think the average age of our developers is 24 or something) who already do a great job, and they're constantly getting better.

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

Elegant Code » Guest Blogger

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Elegant Code » Guest Blogger

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Elegant Code » Guest Blogger

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Elegant Code » Guest Blogger

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Elegant Code » Guest Blogger

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

Elegant Code » Guest Blogger

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

Elegant Code » Guest Blogger

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Elegant Code » Guest Blogger

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Elegant Code » Guest Blogger

Guest Blogger — Sun, 15 Feb 2009 21:38:57 +0000

Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

NHibernate and Future Queries

Guest Blogger — Sun, 25 Jan 2009 11:04:05 +0000




            using (ISession session = sessionFactory.OpenSession())
            {
                // this executes the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).List();                
                // this executes the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).List();
 
                foreach (var category in categories)
                {
                    // do something
                }
 
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }




            using (ISession session = sessionFactory.OpenSession())
            {
                // this creates the first query
                var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();
                // this creates the second query
                var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();
 
                // this causes both queries to be sent in ONE roundtrip
                foreach (var category in categories)
                {
                    // do something
                }
 
                // this doesn't do anything because the suppliers have already been loaded
                foreach (var supplier in suppliers)
                {
                    // do something
                }
            }

Abstracting Request State

Guest Blogger — Sat, 17 Jan 2009 15:20:57 +0000




    public interface IRequestState
    {
        T Get(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right? Then we have the ASP.NET implementation:




    public class AspNetRequestState : IRequestState
    {
        public T Get(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }




    public class MyExtension : IExtension<OperationContext> 
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }




    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<MyExtension>();
 
                if (extension == null)
                {
                    extension = new MyExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get(string key)
        {
            return (T)State[key];
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Framework Configuration: A Different Approach

Guest Blogger — Mon, 12 Jan 2009 21:21:49 +0000




namespace Trinity.Business
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly businessAssembly)
        {
            CommonAssembly = commonAssembly;
            BusinessAssembly = businessAssembly;
            SetDefaultImplementationTypes();
        }
 
        public Assembly BusinessAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
        public Type IRequestProcessorImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            IRequestProcessorImplementation = typeof(RequestProcessor);
        }
    }
}




    public class RegistrationWithNHibernateSupport : Registration
    {
        public RegistrationWithNHibernateSupport(Assembly commonAssembly, Assembly businessAssembly, 
            string mappingAssemblyName) : base(commonAssembly, businessAssembly)
        {
            MappingAssemblyName = mappingAssemblyName;
            SetDefaultImplementations();
        }
 
        public string MappingAssemblyName { get; private set; }
        public Type ISessionProviderImplementation { get; set; }
        public Type IActiveSessionManagerImplementation { get; set; }
        public Type IUnitOfWorkImplementation { get; set; }
 
        private void SetDefaultImplementations()
        {
            ISessionProviderImplementation = typeof(SessionProvider);
            IActiveSessionManagerImplementation = typeof(ActiveSessionManager);
            IUnitOfWorkImplementation = typeof(UnitOfWork);
        }
    }




    public static class Register
    {
        public static void WithNHibernateSupport(RegistrationWithNHibernateSupport registration)
        {
            Normal(registration);
            RegisterNHibernateComponents(registration);
            RegisterAllRepositories(registration.BusinessAssembly);
        }
 
        public static void Normal(Registration registration)
        {
            RegisterRequestProcessor(registration);
            RegisterRequestAndResponseTypes(registration.CommonAssembly);
            RegisterRequestHandlers(registration.BusinessAssembly);
        }
    }

I left out the implementations of the private methods for brevity. Although i will show you what the implementation of the NHibernate components looks like:




        private static void RegisterNHibernateComponents(RegistrationWithNHibernateSupport registration)
        {
            IoC.Container.Register(Component.For<ISessionProvider>()
                .ImplementedBy(registration.ISessionProviderImplementation)
                .Parameters(Parameter.ForKey("mappingAssemblyName").Eq(registration.MappingAssemblyName))
                .LifeStyle.Singleton);
 
            IoC.Register(typeof(IActiveSessionManager), registration.IActiveSessionManagerImplementation, IoC.LifeStyle.Singleton);
            IoC.Register(typeof(IUnitOfWork), registration.IUnitOfWorkImplementation);
 
            // these 2 component implementations can not be overridden by consumers (why yes, that _is_ on purpose)
            IoC.Register<IQueryBatcherFactory, QueryBatcherFactory>(IoC.LifeStyle.Singleton);
            IoC.Register<IQueryBatcher, QueryBatcher>();
        }




            Assembly businessAssembly = Assembly.GetExecutingAssembly();
            Assembly commonAssembly = typeof(EmsRequest).Assembly;
 
            var registration = new RegistrationWithNHibernateSupport(commonAssembly, businessAssembly, "EMS.Mappings")
                {
                    IRequestProcessorImplementation = typeof(EmsRequestProcessor),
                    ISessionProviderImplementation = typeof(Infrastructure.NHibernate.SessionProvider)
                };
 
            Trinity.Business.Register.WithNHibernateSupport(registration);




namespace Trinity.WebForms
{
    public class Registration
    {
        public Registration(Assembly commonAssembly, Assembly webAssembly, 
            Type resourceManagerFactoryImplementation)
        {
            WebAssembly = webAssembly;
            CommonAssembly = commonAssembly;
            IResourceManagerFactoryImplementation = resourceManagerFactoryImplementation;
            SetDefaultImplementationTypes();
        }
 
        public Assembly WebAssembly { get; private set; }
        public Assembly CommonAssembly { get; private set; }
 
        public Type IResourceManagerFactoryImplementation { get; set; }
        public Type ITextRepositoryManagerImplementation { get; set; }
        public Type ISessionStateImplementation { get; set; }
        public Type IRequestProcessorImplementation { get; set; }
        public Type IDispatcherImplementation { get; set; }
 
        private void SetDefaultImplementationTypes()
        {
            ITextRepositoryManagerImplementation = typeof(TextRepositoryManager);
            ISessionStateImplementation = typeof(WebSessionState);
            IRequestProcessorImplementation = typeof(RequestProcessorProxy);
            IDispatcherImplementation = typeof(Dispatcher);
        }
    }
}

And well, i guess you can imagine what the rest looks like :)

Ethics In Software Development: Pragmatism Over Dogmatism

Guest Blogger — Sun, 11 Jan 2009 21:20:25 +0000

Recommended Books: Behind Closed Doors, Secrets Of Great Management

Guest Blogger — Sun, 11 Jan 2009 19:19:52 +0000

The Life And Times Of A Bug

Guest Blogger — Fri, 02 Jan 2009 13:01:06 +0000

October 15, 2008

October 23, 2008

October 30, 2008

December 3, 2008

December 5, 2008

December 6, 2008

Hmm, i haven't been triggered anymore so i guess nobody wrote a test case to truly expose me yet. I feel good about that, but i am getting more nervous with each passing hour.

December 16, 2008

December 22, 2008

December 24, 2008

December 27, 2008

December 29, 2008.... 10PM

December 29, 2008... 11:30PM

Hah, this rookie screwed around... i'm a proud father now!

December 29, 2008... 11:55PM

Damn it! He must have realized the risk he was taking and he reverted all of his changes. He killed my babies before they were ever committed!

December 30, 2008... 7PM

Oh great, he's back for more... I can't wait for him to screw this up again.

December 30, 2008... 8:28PM

Oh crap... i think he's got a fix ready... this is gonna be the end of me... i can feel it :(

December 30, 2008... 8:30PM

What Would You Choose For New .NET Web Development?

Guest Blogger — Mon, 29 Dec 2008 12:36:17 +0000

Junior Vs Senior Developers?

Guest Blogger — Mon, 29 Dec 2008 00:49:15 +0000

Tired Of Working With Big Visual Studio Solutions?

Guest Blogger — Mon, 29 Dec 2008 00:36:28 +0000

Ever noticed how Visual Studio can be painfully slow when it comes to working with big solutions? It starts using large amounts of RAM, building the project takes way too long, and with practically every change you make it has to rebuild a lot of the projects in the solution which can waste a tremendous amount of time if you add it all up. Consider the following solution: Now, i'm not going to get into the specifics of each project in this solution... most of these projects were created before i ever got involved with this project, and i'm not really happy with the entire structure. It's a pretty big application, and a while ago we decided to move to a new architecture. But since we can't just rewrite the whole thing, we put the new stuff (using the new architecture) in the same application and we're going to gradually rewrite the old parts using the new architecture. I wanted to keep the new stuff completely separated from the old stuff, so i added more projects to it (the EMS.* projects). Before i added the new projects to the solution, it was already painfully slow to use this solution with Visual Studio. After adding the new projects, it obviously only got worse. Since we're spending most of our development work in the new projects, i wanted to see if i could simply create a new solution which would contain only the projects we usually need. That new solution looks like this: Much better.... but now you're probably thinking: doesn't CMS.WebApplication reference any of the other projects? It does reference a few of them actually: Visual Studio indicates that it can't resolve these references. So this new solution isn't usable, right? Well, it is actually. You just have to make sure that you've done a full build of the entire solution (the one that has all of the projects in it) before you build the small one. If you use the small solution after you've built the big one, Visual Studio is smart enough to remember where it got those compiled dependencies from in the first place. So is this really usable? It sure is... we do most of our work in the smaller solution, and we can modify and recompile as much as we want without problems and without wasting huge amounts of time just waiting for Visual Studio and the compiler. The only issue we have with this approach is when we need to make changes in some of the older projects that aren't in the small solution. Whenever someone makes a change there that requires a recompile of the CMS.WebApplication project, every teammember needs to recompile the entire big solution. But to avoid having to load the entire solution in Visual Studio, you can just run the following command in a Visual Studio 2008 Command Prompt:


msbuild ems.sln

and it builds the entire solution without using Visual Studio. After that, your smaller solution will work again. If you're working with big Visual Studio solutions and the slowness of this bothers you, be sure to give this a shot. You can create as many of these small solutions as you like, depending on which parts of the codebase you typically need to work with. It can easily save you a lot of time, and avoid unnecessary frustration as well :) For new solutions, i think it's better to just keep the number of projects to a minimum which i've explained previously here