Microsoft? .NET: Architecting Applications for the Enterprise (PRO-Developer)
List Price: $39.99

Our Price: $19.99

You Save: $20.00 (50%)


Product Description

Make the right architectural decisions up front and improve the quality and reliability of your results. Led by two enterprise programming experts, you ll learn how to apply the patterns and techniques that help control project complexity and make systems easier to build, support, and upgrade right from the start. Get pragmatic architectural guidance on how to: Build testability, maintainability, and security into your system early in the design Expose business logic through a service-oriented interface Choose the best pattern for organizing business logic and behavior Review and apply the patterns for separating the UI and presentation logic Delve deep into the patterns and practices for the data access layer Tackle the impedance mismatch between objects and data Minimize development effort and avoid over-engineering and deliver more robust results Get code samples on the Web.

Customer Reviews:

  • Excellent reference for an architect
    For a long time I have been searching for a good & easily understandable book on application architectures & patterns and finally my search ended with this book.
    I have read P of EAA Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) before but this book provides good context and examples around each of the patterns mentioned in P of EAA.
    couple of -ves I see in this book are,
    1) there's no clear-cut examples for certain concepts that authors are trying to make in the book (e.g. application logic vs. business logic)
    2) Although it provides good overview of all patterns including the ones related to yesterday's architecture (e.g Transaction script) I think more info, examples, best practices should have been provided on patterns more relevant to today's Enterprise applications (e.g. domain model)

    Never-the-less I would recommend every architect to keep this in their reference library....more info
  • If you want to know the current .NET architectural trends, this is a must read
    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 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.
    ...more info
  • Gospel on Architectuire in 2009
    This is a great book. It discusses everything that you need to know about Modern Architecture in .NET world. I found Discussions of TS vs TM vs ActiveRecord Vs PI extremely interesting and awakening. Concept of Service layer is discussed in depth. It discusses all Data Layer, Business Layer, Service Layer, Presentation Layer in great detail.

    This book should be in library of every .NET Architect....more info
  • Great book
    I'm in agreeance with most of the other reviews. I wanted to give this a 5 but I agree with the other 4 star that what prevents me from giving a 5th star is the lack of relevant examples. This will largely be a preference of the person purchasing the book.

    The books states early to look at a group effort of some Northwind example but for me I like to have working samples as I go through a book. As I've said in other reviews, that's the point of me spending money on a book. We are limited on time and are looking for a go to where every thing is in one place and is easy to follow along.

    The book, even without great sample code is well written and easy to identify with. I've been looking for a book like this for 2 years. Great work and would recommend it to any software developer looking to make themselves better.

    ...more info
  • Written to be understood, not to complicate
    Author's use of common English language and easy-to-use explanations really stands out in this book. As a developer, I feel that I've gained a tremendous amount of new understanding of architectures from this masterpiece. This certainly isn't a reference book, however. Rather, it's a very nice walk-through and introduction into the world of architecture and patterns. Some advanced concepts are also present and the author seems to have an excellent grasp of emerging technologies. Explanation of O/RM tools and why you should probably look into them is great as well.

    Read it, no matter what level you are on the subject. Just don't expect this to be a bible on architectures....more info
  • A Great Asset
    I am extremely pleased with this book. I have found that it is an easy read and that the information contained is pertinant to my current job. There are a lot of "ah ha" moments where I was able to piece together forgoten theories from Computer Science classes. A lot of what the authors talk about is common sense but it is nice to see it in print.

    It is also nice to see that the authors are not shoving specific Microsoft products down your throat. They do a good job of listing out third party, open source frameworks that tie nicely into the .Net framework .

    There is just enough information to give you an understanding of the topic at hand. And when more information is needed, the authors give you links to resources on the net.

    Overall I would recommend this book to every .Net developer.
    ...more info
  • recommend it for intermediate to senior developers
    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, its 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:
    Information Hiding
    Separation of Concerns
    Business Objects vs Domain Objects
    Liskov's Substitution Principle
    Dependency Inversion Principle
    Dependency Injection and Inversion of Controls
    maybe a dozen or so design patterns chosen to work best with business apps
    Security Development Lifecycle (STRIDE & DREAD)
    Aspect Oriented Programming AOP

    these 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.....more info
  • Good Architecture and Design book
    very good book, well written and useful if you are in the world of enterprise .net applications.
    Delivers in an area that is lacking in the .net world and give you a good picture of valid architectural an design patterns....more info
  • Next release of Fowler's "Patterns of Enterprise Application"
    I have enjoyed reading this book and highly recommend it. This book gives a fundamental overview of basic step necessary to develop an enterprise application. The book shares a fundamental considerations necessary to make when designing an app: Principles, patterns, aproach for design.

    Those who red Martin Fowler's "Patterns of Enterprise Application" (EA) had discovered that Dino applied the concepts of Martin Fowler's masterpiece. You really need to have both books at hand as Dino is referencing EA extensively.

    I believe that this book would be good for senior developers and junior to mid-level architects as they can finally learn what their job is about :) For more senior guys it is also good to have at hand for reference purpose.

    I hope this review will help somebody to make


    Alexander Koval ( info
  • Written in 2nd person, 2nd language.
    This is a really good book. It has great information that is difficult to find in other places. However, as I read the book, it is becoming extremely evident that it is written by two different authors.

    Overall review: Poor editing makes it difficult to grasp the authors' points.

    The following sentence from Chapter 1 perfectly exemplifies the book's writing:

    [The word "architecture" is indissolubly bound to the world of construction.]


    It feels like one author says something, then the other author jumps in and says, "Oh, but I think..." This creates a kind of jumbled writing that doesn't flow.

    Some of the sentences don't parse quite right in English and seem to distort the meaning. Precise language is needed for book a book that is describing a precise process like Software Architecting. The imprecise language makes the book feel sloppy.

    For example:
    "As you can see in Figure 1-1, the Architecture is described by one Architectural Description."

    This should really read: " described by one [possible] Architectural Description."

    The following is just a jumbled sounding sentence that could mean a great number of things:
    "At the end of the day, you serve different and concurrent views of the same architecture and capture its key facts."

    Those are short samples of something that is better shown by the long example below (between the [[--- and ---]]. In the sample below the authors speak about a [border]. They explain it one way, then throw in an unneeded analogy about apples, and then bend the understanding of the [border] into another explanation. After reading this section, it's quite confusing to grasp their point.

    Defining the Borderline Between Architecture and Implementation
    The constituent components you identified while breaking down the system represent logical functions to be implemented in some way. The design of components, their interface, their responsibilities, and their behavior are definitely part of the architecture. There's a border, though, that physically separates architecture from implementation.

    This border is important to identify because, to a large extent, it helps to define roles on a development team. In particular, it marks the boundary between architects and developers. Over the years, we learned that architects and developers are not different types of fruit, like apples and oranges. They are the same type of fruit. However, if they are apples, they are like red apples and green apples. Distinct flavors, but not a different type of fruit. And neither flavor is necessarily tastier.

    You have arrived at the border between architecture and implementation when you reach a black box of behavior. A black box of behavior is just a piece of functionality that can be easily replaced or refactored without significant regression and with zero or low impact on the rest of the architecture. What's above a black box of behavior is likely to have architectural relevance and might require making a hard-to-change decision.

    What's our definition of a good architecture? It is an architecture in which all hard-to-change decisions turn out to be right. ---]]

    ...more info