|  | Authors: Dino Esposito, Andrea Saltarello
Publisher: Microsoft Press
List Price: $44.99
Buy New: $26.56
as of 11/22/2009 05:26 CST details
You Save: $18.43 (41%)
New (31) Used (9) from $24.55
Seller: a1books
Rating:  21 reviews
Sales Rank: 7195
Languages: English (Original Language), English (Unknown), English (Published)
Media: Paperback
Pages: 304
Number Of Items: 1
Shipping Weight (lbs): 2.1
Dimensions (in): 8.7 x 7.3 x 1.1
ISBN: 073562609X
Dewey Decimal Number: 005.2768
EAN: 9780735626096
ASIN: 073562609X
Publication Date: October 15, 2008
Availability: Usually ships in 24 hours
Condition: Fulfilled by Amazon. Buy with confidence. Over 6 million customers served. Order now. Selling online since 1995.
|
| Customer Reviews:
Showing reviews 6-10 of 21
Gospel on Architectuire in 2009 June 4, 2009
P. C. Mehta
1 out of 1 found this review helpful
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.
Good Architecture and Design book May 4, 2009
S. H. Polen
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.
Next release of Fowler's "Patterns of Enterprise Application" April 29, 2009
Alexander Koval (Boca Raton, FL United States)
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
regards,
Alexander Koval (http://www.grandmasterit.com)
A Great Asset April 14, 2009
David M. Davis (Boston, Ma)
1 out of 1 found this review helpful
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.
 Written in 2nd person, 2nd language. April 9, 2009
Daylight (Ohio)
9 out of 15 found this review helpful
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.]
Indissolubly?
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: "...is 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. ---]]
Showing reviews 6-10 of 21
|
|
|
