Author: Bradley Irby
Audience: .NET devs needing to update legacy applications
Reviewer: Mike James
You might think that .NET is too new a technology to need deep reengineering techniques but it is never too early to refactor what you already have.
The most important thing to realize about this book is that it isn't about reengineering .NET but rather applications built using .NET. In other words, this isn't about compiler technology or systems programming. Its subtitle gives you more information on what it is about: Injecting Quality, Testability, and Architecture into Existing Systems. If you have encountered the ideas and patterns of a service oriented architecture then you probably don't need to read this book - partly because you already know many of the ideas but also because you are unlikely to have made the mistakes that this book is trying to get you to correct.
Part I of the book considers the theory and what what the architecture of choice should be. Chapter 1 introduces the basics of service-oriented architecture -- what coupling and statelessness is all about.
Chapter 2 becomes more specific and explains MVP, MVC and MVVM in the context of .NET. How to pick which variant of the model is also discussed. Even if you already know what this decomposition of responsibility is all about it is good to have them compared directly and with .NET and XAML in particular in mind.
Chapter 3 is on unit testing , Chapter 4 is on dependency inversion and Chapter 5 looks at using test doubles, i.e mocking, with unit tests.
You can consider Part I as being a statement of what you should know before you start to reengineer and Part II being about getting started on the job. Chapter 6 explains the ideas of analyzing the code. This seemed very vague and hands off with very general comments on subjects such as removing dead code and investigating the source. Despite the fact that automatic aids keep on being mentioned, no concrete examples are given.
Chapter 7 is about the conversion project and it too is vague; it introduces defect tracking using CI server and so on. Again there's no real advice as to the correct tools. Chapter 8 claims to explain what tools are available but it too is vague - use a source control system, but which one? Towards the end of the chapter we have some very short descriptions of Subversion, TFS and, inevitably, Git. Then we consider the use of Visual Studio and the tools it provides, but these really don't seem up to the job.
Chapter 9 is titled "Cleaning up Legacy Solutions" but I thought this is what we were already considering. It deals with changing the project's file structure to better fit with new project types. The later part of the chapter starts to look at much more code-oriented examples - move initialization logic into the constructor, and so on, but this comes to an end all too soon.
Chapter 10 introduces Prism, Unity, Entity Framework and more, alongside the existing project. What is happening is that the new infrastructure is assembled so that in Chapter 11 we can start to move existing code into the new framework and adding unit tests as we go. Chapter 12 is about advanced refactoring to services, chapter 13 is about refactoring to a controller and the book ends with an appendix on using Visual Studio 2012.
I find it difficult to come to a single verdict on this book. On the one hand I enjoyed reading some parts of it while others were too vague to be useful and contained advice that was obvious. It also isn't sufficiently hands on with Visual Studio for me, and it doesn't suggest tools that I might use for code coverage and static analysis.
Then there are places where it suddenly gets too specific. For example Prism, Unity and the Enterprise library are all introduced in Chapter 10 without enough preparations for the why or what they are for. On the other hand, there are lots of examples and if you like learning by example you will enjoy those sections.
If you already know about MVC, IoC and unit testing then most of Part I of the book is going to be revision. There were also places where I got completely lost as to what the section of the book was trying to tell me - occasionally the bigger picture is missing. The best thing about Part II is the it provides a plan of attack in how to move your legacy application to a service-oriented design without throwing all of the code away.
Overall this is a useful, if not essential, book if you are planning to "improve" any existing systems using .NET.