Continuing my series of great books I've read in the last months and years, here are some additional .NET books for advanced software development I really enjoyed reading:
Pro .NET 1.1 Remoting, Reflection and Threading
Advanced .NET Remoting, Second Edition
COM and .NET
Foundations of Object Oriented Programming Using .NET 2.0 Patterns

Some people might say "oh, some of them are pretty old...". Yes, some of them are and if you haven't read them by now, you definitely should! Some people might think that COM+, internals of .NET 1.1 like Reflection and Threading and OOP in .NET 2.0 are "yesterday's news" in times of .NET 3.5 and WCF. Well, they aren't. These books are some of the best about the general .NET architecture available today and you should take a look if you really want to know what's going on behind the scenes.

Of course there are some newer books I will read in my upcoming vacation and although I cannot give you any report about there usefulness now, yet I want to share their titles with you:
Practices of an Agile Developer
Software Estimation - Demystifying the Black Art
jQuery in Action
The Art of Software Architecture
The Art of Project Management

Well, I have about eight days sun and beach, so let's get started! :-)

Some days ago I started to develop a new base library. The goal is to create a common set of features and a reference application for creating entity objects in our applications that provide validation, n-level undo, in-memory transactions and some other advanced features out of the box.
To separate those features from the plain value objects (which of course should not have to deal with all the stuff) I created my own AOP mechanism based on the native ContextBoundObject infrastructure in .NET.
There are different reasons why I couldn't use Spring.NET or PIAB and decided to go my own way. The main reason is that our persistence frameworks (ORM's like NHibernate and the ADO.NET Entity Framework) create the models behind the scenes and I haven't figured out yet how to really intercept that creation process to replace the model objects with transparent proxies or interfaces. The only clean interception point I could find in NHibernate so far is based on the new event model in 2.0b, where I was able to intercept the objects right after their creation and before NHibernate sets all their values - but I couldn't replace the object itself at that stage with an interface, a proxy or a wrapped version of the object. So I decided to try my own way.
.NET has a lot of more or less "secret" features that allow advanced software development techniques like DI, AOP and other stuff. The problem is that there is a reason why they are "hidden" and should only be used with care.
My own AOP implementation is - as I said - based on the .NET context architecture. Every model has to inherit from ContextBoundObject and it has to use at least one of my ContextAtrributes to get all the additional functionality. When a new model object (named DemoModel here) is created, .NET is constructing a new context within the current AppDomain, places the new object in that context (actually the object is created right in the context) and we can intercept any call to it using the .NET IMessageSink architecture.
I knew that the introduction of an interception mechanism like that would come with a price because .NET has to marshal the call to the object through the IMessageSink chain whenever an object from the outside of the context tries to access it.
To get a feeling for the hit on performance, I made a little test and created 100.000 objects, set a string property to "Test" and measured the time. To avoid Garbage Collection to take place, I added all the objects to an in-memory arraylist. I created the first test without any optimization so that the runtime had to create a completely new context for every of my DemoModel objects.
It took .NET nearly 27(!) seconds to create 100.000 new objects (each with its own context) and set the property - compared to 0.04 seconds for 100.000 plain vanilla objects. That's more than 600 times slower.
For everyone who is familiar with the context architecture in .NET, there is a logical thing we can do to decrease the overall overhead. Whenever .NET is creating a new ContextBoundObject, it checks if the context of the parent that is creating it (the object that is calling the constructor) is sufficient enough for the new object. If so, it creates the new ContextBoundObject in the context of the caller.
To optimize my tests, I created a ModelRepository class (which is the default way at netzkern to handle resource abstraction in our internal software reference model, anyway) that itself is placed in a context when it is created. That context has the exact same requirements (the same context properties, to be precise) as the DemoModel demands when it's created by the runtime. When .NET is asked by the factory method in ModelRepository to create a new DemoModel object, it will find the current context accurate enough for the new ContextBoundObject to be placed in and omit the creation of a new context.
When I ran my second test, I was very surprised. Although all the objects were placed within the same context (I checked it using the Thread.CurrentContext property called from within(!) the DemoModel objects), it took the runtime about 25 seconds to construct 100.000 objects - only 2 seconds less than creating 100.000 objects, each in their own context. My IMessageSink is based on the ObjectSink functionality in .NET, so I already knew that the runtime always had to create a transparent proxy to make sure that the ContextBoundObject is never called directly even if the call is coming from the inside of its own context, but I wasn't aware of the fact that it would cause such a performance hit. I changed my IMessageSink to a ServerContextSink (which intercepts the call at the edge of the context, not at the object), but it didn't change a thing.
I removed the set property call from the for loop that is responsible for creating the 100.000 objects and the time dropped to 20 seconds. So it seems, about 20 percent of the overhead introduced by this technique is caused by marshaling a simple method call from context to context.
Obviously, the remaining 20 seconds (or 80 percent) are the price to pay for an AOP solution based on ContextBoundObject.
When the patterns&practices group at Microsoft released the PIAB, they explained in a blog post why they chose not to use ContextBoundObject as their base class, although their approach means slightly more work for the developer - I think, the performance impact I demonstrated here is the main reason.
I haven't decided yet whether I will use the technique tested in this experiment or not, because it heavily depends on the number of model objects that need to be created and the number of calls to methods and properties of those objects. But I keep you posted.

Everyone knows, I'm a freak when it comes to books. Usually, I read about one book a week (although I didn't in the last couple of weeks, but usually I do). As of now, I've read about 180 books about .NET, Software Architecture and Java EE, as well as some other topics like Ruby on Rails, Requirements Management, Personal Productivity and Management.

My family gifted me that incredible ebook reader from iRex, the Iliad about 1.5 years ago, and so I can take a large number of books with me on vacation, when I'm traveling or just having breakfast in a cafe. I'm also a proud owner of an iPod and an iPhone, so listening to audiobooks and reading newsfeeds (Google Reader is great on the iPhone) on the move are other great ways to learn steadily.

There are, however, some books that are really great and I actually read them two or three times, at least in parts. Today I want to share those book tips with you and I hope, you enjoy them as much as I did.

Advanced .NET Software Development
Pro Scalable .NET 2.0 Application Design
Programming .NET Components, 2nd Edition
Programming WCF Services
Debugging Microsoft .NET 2.0 Applications
JavaScript - The Good Parts
Professional ASP.NET 2.0 Server Control & Component Development
.NET Framework 2.0 Application Development Foundation
Professional ASP.NET 3.5
ASP.NET AJAX Programmers Reference
CLR via C#

Software & Solution Architecture
Patterns of Enterprise Application Architecture
Windows via C/C++

Self Development & Personal Productivity
Getting Things Done
Ready for Anything
The 7 Habits of Highly Effective People
Mind Performance Hacks
How to Be Brilliant

Management
Behind Closed Doors
Good to Great

I will extend this list further in the next few months. The most important thing to keep in mind while reading is the following: Your unconscious mind can process information much faster than your conscious mind - don't try to understand everything in the moment you read it. Fast-read the whole page and then stop at the end and think a couple of seconds with closed eyes about what you've just learned. In my experience, this way makes your reading three times more productive.

Obviously there are a lot of very interesting technologies out there that should help every developer to create great .NET-based web applications. Unfortunately with .NET growing faster with every year, the rising number of conceptually overlapping technologies sometimes creates confusion and insecurity, especially in the beginners developer community. "What .NET framework should I use?" is a common question these days.

Coming from the Java EE world I remember a time a couple of years ago when we were developing with different Java web frameworks. I worked a lot with JSF and Spring Web MVC, but we also used Struts, Beehive, Tapestry, Cocoon and some other in different projects. Whenever we started a project using one particular framework, we usually had to stick with it or we had to create a completely different application root and development style when we decided to add another framework to the toolset that could fulfill the requirement with more elegance and effectiveness than the primary framework.

When I look back at that time now, I see the need for guidance in our world and I see that we have to make good choices in our technical strategy. I will try to provide this guidance in this article, but I invite you to share your thoughts and views with me. First of all, I have to say that I have always been a fan of a very "clean" development style. "It runs" is not enough for me.

Having said that, I have to admit that ASP.NET WebForms aren't really the cleanest way to develop web applications - or better, most people are somewhat lazy and take the path of the least resistance, so they use WebForms in a "dirty" way: They don't use data binding (either native ASP.NET or Spring.NET), events and customer controls appropriately. Instead they directly assign values to properties in code-behind files at several states of the page lifecycle and wonder why they get Spaghetti code in their Page_Load and Page_PreRender methods. Sometimes they even get strange results because they lack the knowledge of the page lifecycle in WebForms. Well, of course there is a better way, but because the WebForms model is more or less a "conceptual porting" of the WinForms model to the web and because it tries to support a development style that is based on state by emulating several desktop-like environmental conditions, the root of the problem lies in the underlying architecture of the framework.

The Sitecore development model uses several features of ASP.NET WebForms. But by taking a closer look at the system, it actually becomes clear that there is no real dependency between Sitecore and the WebForms model - it is just one way to create Sitecore renderings. I'm pretty sure that Sitecore will work very well with ASP.NET MVC in the near future, because it is in itself an implementation of a FrontController pattern with different View engines. The most common ones (Web Controls, Sublayouts, XSLT renderings) happen to be based on the WebForms model.

(By the way, you could use XSLT without ASP.NET WebForms, but by just placing XSLT output in typical content zones of the website using Sitecore Web Controls, the definition of overall website design with standard HTML and WebForm tools is much easier.)

So, apparently being a Sitecore developer is a very good starting point for learning ASP.NET MVC. With ancestors like Struts and Ruby on Rails the whole approach of the Model-View-Controller pattern has been proven very useful in the last couple of years. ASP.NET MVC not only removes the curiosities that had to be introduced with the WebForms model to support the Postback mechanism and the event emulation, it also focuses much more on things like cross-page navigation, meaningful URLs and a better separation of concerns (routing, integration logic, presentation). Instead of trying to hide the way the web is really working and to replace it with a sometimes inconsistent and emulated desktop-like development model, it acknowledges that way and provides appropriate tools and helpers for developers to deal with request / response sequences.

As you can see, I like the way ASP.NET MVC is doing things and I also like the possibility to use some ASP.NET WebForms features "in the back".

So, what's wrong with the page / control model in ASP.NET WebForms? Nothing. Actually, the only thing we need to do is to shift it to a place where it works in a more natural way. Well, in my opinion, that place is the client. And that is exactly what the Microsoft AJAX Library is trying to do. So, why's that? First of all, the client has something that the Postback machanism can only simulate - the client has real state. Because of that, client-side events are really what they pretend to be: A way to respond to a actual user interaction directly without the need to "recreate" the whole state of the page first, perform the changes and then send it back to the client. Usually we need data to perform the operation that has just been triggered by a user, so what do we need to do now? Well, here is the revival of the good old client-server-architecture: We use WCF and client-side JavaScript proxies to communicate with the server and receive updated data structures directly. So instead of using slow UpdatePanels that complicate the whole Postback model further and create additional load on the client without reducing the work on the server, we let the server serve the data and our client update the user interface. We are not bonding an inconsistent framework with additional band-aids just because "it's so easy to use". We face the challenges of Web 2.0 and use our know how to create a responsive, well-designed Rich Internet Application by using client-side technology (like JavaScript with the Microsoft AJAX Library or Silverlight) for the user interface and server-side technology for cross-page navigation, initial response creation, business logic and the transformation of information.

So, what is the master way to go? Our future applications take the following approach: The first rendering of a webpage is done by Sitecore or ASP.NET MVC, sometimes using some ASP.NET controls in the back, ideally with DataBinding. After the initial page has been received by the client, we switch to "real" AJAX and use object-oriented JavaScript to create straight user interface logic using the Microsoft AJAX Library and communicate over Web Services with our WCF services on the server-side. There might be situations where it is appropriate to use partial rendering features of ASP.NET MVC, but ASP.NET WebForm pages with Postbacks and UpdatePanels are definitely in the past.