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.
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required.
Read instantly on your browser with Kindle for Web.
Using your mobile phone camera - scan the code below and download the Kindle app.
Follow the authors
Something went wrong. Please try your request again later.
There is a newer edition of this item:
Top reviews from other countries
David G
Great books for engineers and architects
Reviewed in the United Kingdom on December 8, 2013Andrew Perkin
A great book that now needs an upgrade
Reviewed in the United Kingdom on May 19, 2014
