I am thinking doing a course in Warsaw around the end of October. Before setting out to figure all the details, and with the caveat that this is still very early in the game, etc. I would like to solicit some input from you guys (well, if you are in Poland or nearby.

• Would you come?
• What level do you think the course should be?

Continuing my review of http://microsoftnlayerapp.codeplex.com/, an Official Guidance (shows up at: http://msdn.microsoft.com/es-es/architecture/en) which people are expected to read and follow.

Take a look at the following:

It is obvious that someone recognized that there are distinct responsibilities in here.

It is just sad that C# doesn’t give us better way to split responsibilities other than regions and partial classes.

I mean, if we could have defined multiple interfaces and multiple classes… but that is crazy talk, no one needs to have multiple classes in their applications, what are we, Java?

One of the things that we worked very hard on (and are still working very hard) is making RavenDB as streamlined as possible, in the sense of making it very easy to do things that you commonly have to do.

Case in point, the Future Posts feature of this blog. Yesterday I went a bit overboard and posted about 10 posts in the space of two hours. (No, this isn’t my usual rate). That led to something that I didn’t quite foreseen:

We did have a limit on the number of future posts that we will show, but that limit was set to 15, and as you can see, it is actually pretty hard to look at things when we have so many, so instead I decided that we should have the following:

Just a minor UI change, but we now need to also change the data that we gather, or do we? Let us look at the code:

The only change that I actually had to do was modify the Take() from 15 to 5, and also ask the query to give me the query statistics. Because such as operation (pages + full count) is so common, RavenDB make it super cheap to do so. You don’ t need to issue a separate query, and you don’t need to do anything nor are you incurring any additional costs.

The information is already there.

Continuing my review of http://microsoftnlayerapp.codeplex.com/, an Official Guidance (shows up at: http://msdn.microsoft.com/es-es/architecture/en) which people are expected to read and follow.

From the evidence, it seems that there has been some (lacking, insufficient and usually causing damage, but some) attention given to cross cutting concerns:

That is why I was shocked to read method after method that read like this:

And this:

And this:

I mean, did at no point someone stand up and said: “My Ctrl+C / Ctrl+V keys just fell off, we might need to think about a better way of doing this"?

I mean, cross cutting concerns didn’t raise the question of error handling?

I mean, seriously, you want to tell me that this type of code is an Official Guidance from Microsoft?

Macto is a prison management system. To be rather more exact, it is an incarceration management system. Managing a prison is a very complex process (did you ever think about who takes the trash out? Or how to handle things like watch rotations?).

I am getting ahead of myself, however. The first thing that we have to do when we start designing a system is check:

• What is the scope of the system?
• What is the intended usage?
• Who are the users?
• What other systems are we going to interface with?

Those are the basics, because in a lot of projects, they don’t get asked.

Running a prison is a complex task, I already said. If we wanted a single piece of software to do it all, we would have to do a lot of stuff that we don’t really need. For example, are we going to write our own payroll system for the prison’s stuff? Our own medical software to manage the infirmary? What about managing the inventories in the prison (how many prison uniforms and tear gas canisters we have)? What about the maintenance software for the fleet of vehicles required to run even a small prison?  Or how about… but I think that you get my drift.

There are a lot of aspects where it would be significantly better to get an of the shelve solution rather than try to write our own version of that. We need to be focused where we would provide actual utility to our customer.

That is what I said that we are going to build incarceration system, not a prison management system. Macto is all about managing the aspects of a prison that are different than those of any other business.

You can read about Macto in my initial post about it, here, since it put the context of the system in a nice perspective.

I am not sure if there will be code available, but I am going to outline my thinking here, and I think that this would be valuable in itself.

Macto is going to be about managing the aspects of a prison that you can’t get off the shelve. In order to do that in a way that would make sense to you, I need to first explain what we are going to be doing.

Like any good architect, I’ll be doing that by starting with the model, which is also the cue for the next post.

Update: You can see all the photos here

Well, I might have gone a bit overboard, but I do like Rhinos.

Say hello to my crash of rhinos.

And here is a nice family of them:

I don’t get this way very often, but AWESOME!

Entering to the office…

And just to give you some perspective:

Continuing my review of http://microsoftnlayerapp.codeplex.com/, an Official Guidance (shows up at: http://msdn.microsoft.com/es-es/architecture/en) which people are expected to read and follow.

While investigating how they are implementing IoC, I found:

/// <summary>
/// Configure root container.Register types and life time managers for unity builder process
/// </summary>
/// <param name="container">Container to configure</param>
void ConfigureRootContainer(IUnityContainer container)
{
    // Take into account that Types and Mappings registration could be also done using the UNITY XML configuration
    //But we prefer doing it here (C# code) because we'll catch errors at compiling time instead execution time, 
    //if any type has been written wrong.

    //Register Repositories mappings
    container.RegisterType<IProductRepository, ProductRepository>(new TransientLifetimeManager());
    container.RegisterType<IOrderRepository, OrderRepository>(new TransientLifetimeManager());
    container.RegisterType<IBankAccountRepository, BankAccountRepository>(new TransientLifetimeManager());
    container.RegisterType<ICustomerRepository, CustomerRepository>(new TransientLifetimeManager());
    container.RegisterType<ICountryRepository, CountryRepository>(new TransientLifetimeManager());

    //Register application services mappings

    container.RegisterType<ISalesManagementService, SalesManagementService>(new TransientLifetimeManager());
    container.RegisterType<ICustomerManagementService, CustomerManagementService>(new TransientLifetimeManager());
    container.RegisterType<IBankingManagementService, BankingManagementService>(new TransientLifetimeManager());
    
    //Register domain services mappings
    container.RegisterType<IBankTransferDomainService, BankTransferDomainService>(new TransientLifetimeManager());
    

    //Register crosscuting mappings
    container.RegisterType<ITraceManager, TraceManager>(new TransientLifetimeManager());

}

Just to figure out how ridiculous this is, let me show you the entire infrastructure required to support IoC in this application:

Yes, they abstracted the Inversion of Control Container. I think that if you need to do that, it is pretty clear that you don’t really get what IoC is all about.

Maybe, if you are a framework, you need to abstract the container, but you don't need to do that if you are an application (which this is supposed to be) and you certainly don't write your own, that is why CommonServiceLocator is here.

Then again, the code is absolutely littered with things like:

So I guess that it is not really a surprise.

What is a surprise is that they are catching NullReferenceException. You are not supposed to catch this exception. This is an indication that you have some problem with your code, not that you have some invalid argument issue.

I don’t have the time to actually sit down and build Macto, but I got a couple of people asking about another option. Making Macto into an OSS project that will build this application under my guidance and assistance.

What do I have planned?

Assuming I manage to get a few people (and I’ll probably limit it to a small number), I’ll open a private mailing list and github repository and we will start working on that. I’ll provide guidance and direction for the project, as well as reviewing everything.

This is going to be a private project for about a month, after which we will hopefully have something at hand that we can talk about and show around.

Any volunteers?

Update: Comments are closed, we have enough volunteers

A long while ago I planned on doing a series of webcasts, demonstrating how to build a real Enterprise System using my approach. I called it Macto, but I never got around to it.

The recent discussion around the Microsoft N Layer sample has caused me to rethink this decision. I think that it would be a good idea to do so. I don’t know if I’ll complete it, and I don’t know if I’ll do code, but I intend to lay out a full architectural approach. I already started writing the series of posts, and it should air out starting around the 18th of July.

Update: Okay, I moved some posts around, it is now starting next week, but there is a lot of additional content, so it is going to be posted over the next month or two.

Continuing my review of http://microsoftnlayerapp.codeplex.com/, an Official Guidance (shows up at: http://msdn.microsoft.com/es-es/architecture/en) which people are expected to read and follow.

This quite annoys me:

Why is it annoying?

Because of the author note, it implies that you can switch the implementation to something else. Except that you really can’t.

Take a look at the actual interface, what does it means TraceStop, TraceStart, TraceStartLogicalOperation, TraceStopLogicalOperation? Well, they are all about expose functionality that exists only for the System.Diagnostics stuff.

Too add to the gravity of the situation, there is no where in the code that is even using those methods!

And there there is the actual usage of the trace manager:

No, before that, even, there is the actual name. ITraceManager? Because ILogger or something like that wasn’t important enough? What, pray, does implementer of this interface are going to manage? There is no managing, so there shouldn’t be a manager.

And there there is the actual usage of the trace manager:

Well, let us imagine that we wanted to read the logs of this application. We can’t, because the application, while having a log, is actively hiding important information. Namely, the full exception (including all the inner exceptions and stack trace).

But we will ignore that as well, and say that we want to move to log4net. Guess what, you can’t! Well, you can if you want to get a flat log, but one of the most important features of the log4net is the idea of loggers, that you can dispatch some messages based on their origin to different location (for example, color them differently when writing to the console).

You can’t do that, there is no way of saying what the origin is of anything here.

I’ll touch the “IoC” stuff in a future post, I think that this is enough for now.