About a year ago, through a series of cascading events, I found myself in the position of being the only application architect for the .NET portfolio of a medium sized development shop. Even before that happened, I had read a good deal about architecture, .NET technologies, coding best practices, TDD, design patterns, etc. But it is a bit of a shock to move from reading about all of those things to deciding how to apply them in a practical way. Of course as a developer you have a chance to apply all of that knowledge to whatever code you are working on, and you can influence the rest of the team. But as an architect I found I suddenly had to have a well-defined position on a lot more of these topics, and, if at all possible, that position had to be right.
One of the things I struggled most with was developing a reference architecture for our ongoing .NET application development. We had been using an internally-developed framework since the days of .NET 1.1. But nowadays there is a lot more power in the frameworks available from MS, third parties, and the open source community. And the internal framework was beginning to show its age. It was time to reevaluate.
But, since .NET 1.1, when the previous architecture was established, the landscape has shifted dramatically. Concepts like test-driven development, dependency injection, and object-relational mapping were becoming mainstream. Microsoft had released dozens of different technologies on top of .NET, from new UI frameworks like ASP.NET MVC and Silverlight, to more “behind-the-scenes” pieces like WCF and MEF. Many of these technologies overlapped in functionality, or even conflicted. How do all of these technologies fit together? Which ones should be used and which ones ignored? What was the criteria for choosing one technology versus another? How do you decide what pieces to use to build a particular .NET application?
Since then, I have made a lot of headway in figuring all of this out. It was a lot of hard work, and I think at this point some of what I’ve learned might be useful to others. My hope with this series of articles is to provide the background knowledge necessary for developing an application architecture on top of .NET. Also, I hope to provide some guidance on how different aspects of a particular application affect all of the architectural choices that go into an application.
I will be developing this series over the next couple of months. I think it will be several articles by the time I’m done. I plan to keep this post updated to act as a Table of Contents for the series.
When talking about architecture, it is almost impossible to remove opinion, and there are no absolute right answers. So I welcome any feedback where you agree or disagree with my position.
Table of Contents
- Part 1 – Introduction (you are here)
- Part 2 – Guiding Principles
- Part 3 – Cross-Cutting Concerns
- more to come…