Microsoft® .NET: Architecting Applications for the Enterprise 1st Edition

Prior to reading it I struggled with a few things when it came to developing in .Net. For example, I wanted to further develop my object-oriented skills and thought this would be easy to do. Instead, I found out I was having a hard time reconciling using various ADO.Net features like TableAdapters, DataSets and DataTables, with good object-oriented design concepts. The problem was partly that many online references about programming in .NET dealt with using these ADO.Net objects, along with in-line SQL statements, for accessing data. Even the official Microsoft Course I took (Programming with .Net Framework using Microsoft Visual Studio 2005) emphasized these methods.The tendency to develop in a more procedural style instead of an object oriented one was nearly unavoidable, as exemplified in the examples I found. I even tried for a time to use a layered, object model approach along with DataSets and DataTables and found this to be very clunky to say the least. Now I know why.The book, Microsoft .NET: Architecting Applications for the Enterprise, recognizes this very situation regarding using these ADO.Net objects on page 154 saying, "Each business component then talks to the DAL either directly or through relatively dumb data objects. The logic is implemented in large chunks of code that can be difficult to understand, maintain, and reuse." It refers to such a design as the Table Module Pattern (TM) and further says on page 165, "TM is based on objects, but it's not an object-based pattern for modeling the business logic. Why? Because it doesn't care much about the business and focuses instead on the tables. TM does have objects, but they are objects representing tables, not objects representing the domain of the problem." Additionally, the book does describes very well how the Table Module Pattern can fit appropriately into a program's architecture, as there are times when using this method is warranted.It was reading this book that really opened my eyes on how to go about creating a multi-layer application using true object-oriented design in .Net, and getting away from procedural scripting. Primarily I'm referring to using a domain model along with plain class objects for containing business logic and/or data that are not tied to any database design. The book does a great job in helping one understand how and why multi-layered architecture and domain modeling should be used in complex enterprise applications. This is exactly what I was looking for. It touches on other ways to develop the business layer to an application, as well as the other layers, and provides balanced advice for all approaches.And balance is one thing that stands out in this book. It is not dogmatic at all about how one should construct software. The number one mantra of the book is, "It always depends." With such a refreshing viewpoint, it exposes the reader to a variety of development methodologies and framework. I found this book provides excellent advice on object-oriented design and modern software architecture overall, and specifically on domain-driven design. It also serves as a nice starting point in learning about UML, agile development, unit testing and isolation frameworks, inversion of control frameworks, aspect oriented programming, NHibernate and Entity O/RM frameworks, and the MVC# framework.

This book is divided into two halves - Principles and System Design. The first half of this book is like a computer science course in system analysis and design. In my opinion fairly boring really, unless you are completely new to the subject. It does create a context for the rest of the book and though and even though it was a bit of a chore, I did find some interesting tidbits of information in part 1. The second half of the book moves from the theory of architecting software into the implementation with comprehensive coverage of all the different logical tiers of a system - presentation, service, business and data. It also discusses the different architectures that can be applied depending on the technologies used (forms, web, ria ect). This is where this book really shines. For me the further I got into the book the more I liked it. The writing style is conversational which make this book an easy read, although occasionally the author loses the plot a little, taking half a page to cover a point that could be covered succinctly in one line or two line.By the end of this book I kind of liked it, although having said that it doesn't really offer anything new that hasn't been covered in other books, apart from the fact that the focus is on .Net technologies. For me I don't think this book offers too much to experienced developers, especially those with a lot of experience using .Net. Also for general software architectural principals there are better books around. Being fairly new to the .Net framework I brought this book primarily for an overview of .Net technologies that could be used in architecting applications and the best practices in applying them. In that sense this book is pretty good.So if you're new to architecting software, or want an overview of .Net technologies and frameworks read this book. For experienced .Net folks I wouldn't bother, as this book probably won't teach you too much, except perhaps maybe providing a different perspective on software development.In summary, the first half of this book (principals of software development) I'd rate as 2 stars, the second half (system design), 4 stars.

I've been following Dino Esposito's work for some time, and as usual he delivers great content in a clear and concise (and often humorous) manner. I am only half way through it, and even if i was to stop here, it's already a worthy buy. This is not an in depth exploration of any subject, but a snapshot into many concepts in software architecture with ideas to go off and explorer on your own. There is a brief background of software evolution into the object oriented world, where most of the content of this book resides. It offers a well structured overview of a few key design patterns. Here are some concepts in this book that i found interesting, helpful in my design practices, and explained well:ModularityInformation HidingSeparation of ConcernsCohesionBusiness Objects vs Domain ObjectsLiskov's Substitution PrincipleDependency Inversion PrincipleDependency Injection and Inversion of ControlsAntipatternsMocksmaybe a dozen or so design patterns chosen to work best with business appsSecurity Development Lifecycle (STRIDE & DREAD)Aspect Oriented Programming AOPthese are a handful that stood out for me, and i am looking forward to the Service Layer section which covers one of my favorite subjects, SOA..