This morning I finished reading Dino Esposito's and Andrea Saltarello's book Microsoft .NET: Architecting Applications for the Enterprise. The highest praise for a technical book is that it immediately affected not just the work I was doing, but the way I work. This one did just that.
I've been writing code since I was 8 years old on my school's Commodore PET. That's was almost 30 years ago now. I've been doing it as a career since 1994. I started designing applications (as opposed to just being a code monkey), in 1997. I became what my company calls an Architect last year.
But I didn't start to think like an architect until just recently, and this book, which I power read over the course of 6 days, has had a profound impact on how I see my role within the company, and how I need to work to make myself, and my team more efficient. I've been bringing in tools and processes the last year or so to fix the low hanging fruit, but I still considered myself a developer first, and considered the architect role to be something I did between writing classes and specs.
The first half of this book is about the process. And though the first chapter is a little, um, dry (probably a few too many references to ISO and IEEE), it does help to build the profile for where an architect fits into an organization (big and small). These guys have been there, and done systems development where there is a client involved in the process. They aren't people who have been at some big software company and don't know what is involved in developing line of business software with a client who has no idea what it is they want when the project starts.
The second half of the book talks about application layers: The Business Layer, The Data Access Layer, The Service Layer and The Presentation Layer. I've worked in all these layers at one time or another, but it's only quite recently that I have truly begun to understand the Separation of Concerns rules, and things like dependency injection. This book not only helped top clarify these things in my mind so I can better understand all the other reading that I do that assumes that I know what SoC mean, but it also talked about misconceptions about the layers. I found the section on the service layer particularly appropriate because for a long time, I completely misunderstood Service Oriented Architecture. They cleared this concept up for me in a way no other publication ever has. I wish I had read that 4 years ago. I once built a 'Service Oriented Architecture' application with 80+ web services! What was I thinking?
My favorite part of the book was the 10 Final thoughts, their mantra as they call it. These were spot on, and proved to me that they had been there, and done that, when it came to developing real world applications. It gave them 'geek cred'.
The target audience for this book is probably senior devs and architects. It's probably too high up for low level devs to be interested in (though they should be). I highly recommend it for anyone who is moving up out of the weeds, and anyone who wants a high level picture of some of the most common design patterns in .NET.
The next book I'll be cracking open (tonight on the train ride home), is Julia Lerman's "Programming Entity Framework". 800 pages of data access goodness. Oh My!