Microsoft® .NET: Architecting Applications for the Enterprise

It is a misconception that architecture is a fully understood field. Like the rest of us in the relatively young discipline of software development, architects are making their way along with rules of thumb, buzzwords and trends, too, and doing their best to tie them all together.Microsoft has always been a bit lacking when it comes to providing guidance for developing complex software. The alt.net crowd promised to fill in this lacuna, and even promoted itself in terms of filling in the blanks that Microsoft leaves in its technology offerings. However the results have been, I think, that the contemporary architect simply has more pieces to try to put together, and even more things to try to figure out.Dino Esposito, in "Architecting Applications for the Enterprise", tries to make sense of this technical jigsaw puzzle by building on top of the core architectural concepts of layering and decoupling applications. He then takes these principles forward by seeing how the newest technologies and techniques -- WPF, WCF, Windsor, NHibernate, Entity Framework, MVP, MVC, etc. -- can fit together to form a mature enterprise application.In many ways he cuts through much of the hype and provides insights into why you might want to use these technologies. He is comprehensive in treating each of the various Microsoft and non-Microsoft tools soberly, explaining the pros and cons of each.Best of all, he tries to consolidate in his appendix all of his insights into a core set of architectural principles, one of which he reiterates throughout the book: the job of the architect is to reduce complexity, not increase it. It sounds simple, but many architects tend to forget this.Mr. Esposito's final product is a synoptic view of the current state of software architecture. If you want to know what is currently thought of as best practices in enterprise architecture, then you need to read this book. It will either give you an idea of where you need to be, if you are just starting out, or reassure you that you are on the right track, if you have been following the trends of the past two or three years.The only weakness I found in the book is perhaps the problem that these various tools don't always fit together nicely. For instance, I'm doubtful that ORMs really makes sense anymore if we decide to place them behind service layers. SOA and ORMs rose out of really different architectural problems, and provide somewhat incompatible solutions. Likewise, while the MVP pattern is very nice (we are curently using it on an enterprise project), it tends to break down when you attempt to apply it to anything complex, such as an object graph with more than two or three levels of dependent objects.The book also recommends using interfaces extensively in order to promote testability, but on looking a little closer, this appears to be tied to a specific tool, Rhino Mock, which requires interfaces to be useful, rather to any particular architectural principle -- for instance, TypeMock doesn't require interfaces, but of course it also isn't free. Should your architecture really be tied to a tool in this way, or would it be better to find tools that support your architecture?I tend to think, however, that this is a weakness in the current state of architecture rather than of Mr. Esposito's work. The truth is we are all trying to work this out together, and we are currently only mid-stream in our journey toward mature application architectures."Architecting Applications for the Enterprise" fortunately brings us all to the same point, as software professionals, and allows us to see the horizon for our collective next step forward.

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.

Fundamentally this book covers advanced software engineer practice and techniques to stream line distributed systems. If you know this field well, the early chapters are a nice recap to it all. Found it a very easy read and something I will recommend for many in future.

Hopefully the authors could revisit this book. Enterprise Architecture is far more widely established now and many techniques have been and gone since the document was published. Still a valuable read though, at least if you blow away the Windows Vista and SQL 2000 cobwebs.

It packs lots of scattered knowledge into a coherent whole.Loved it :)www.physics.asia

Nach ein paar Seiten des Buches kam mir der erste Gedanke: Das kennst Du doch irgendwoher. Nach ein paar weiteren Seiten, kam der Gedanke wieder.Wieder ein paar Seiten später, dann der Hinweis des Autors selbst. Es ist ein Werk, das permanent auf Martin Fowlers Architektur Muster verweist.Das Buch bietet inhaltlich wenig neues, wenn man Martin Fowlers Architektur Muster kennt. Mir ist nicht klar warum der Autor dieses Buch geschrieben hat. Es ist wohl eine Art Homage an Fowler. Ich empfehle das Original zu kaufen.