Microsoft Silverlight Books

This is a great book with balanced perspective

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.

Matt
19 August, 2010

Great Book!

I'd just like to say as developer, wanting to become an architect, this book has really opened my eyes. I recommend this for anyone who wants to dig deeper into system architecture and learn how to apply design patterns to your system.

Great book!

Daniel Hoenig
20 May, 2010

Theoretical Pragmatism - The Perfect Mix

What a great treatise after being in a decade of a major suite of VB applications - all "designed" in the VB3/4 mentality - and recompiled in VB5 and VB6. Now - finally - we're migrating to a significantly enhanced architecture which is a welcome change, coupled with a migration to C# - a nice challenge too. This has refreshed my view of OO principles - a needed dusting off for me - and has invoked considerable considerations at the right time in our project.

As many of the reviewers have commented - this is not for the light at heart, nor for the timid. The presentation aptly advises, repeatedly, "it depends", rather than provide a cookbook solution. In the state of our industry, this is a great perspective and forces you to consider before deciding - but nicely lays out facets which should be considered, whether you're quest is a new application, refactored, or one for migration. I particularly enjoyed the theoretical concerns that are tempered with the pragmatic concerns of delivery - very real situations for the architect to fully consider. Best part - the book helps you think through the problems and arrive at the best solution for the project at hand.





David J. Keevis
08 May, 2010

Better than I thought

This is one of my Favorite books, its much better than i thought, the good thing about this book is that it never assume that you are an already professional/experienced programmer, this books guide you from intermediate to advance level in no time, "Must Buy" for any mid term developer.

Nawaz Ali
06 May, 2010

Gets better...

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.

S. Thompson
03 April, 2010

Great Book, maybe a little too "wordy"

I love this book. It really excel in giving a broader view than the mere Microsoft "stack"; for example, it does not insist on LINQ to SQL or the Entity Framework, but praises the benefits of other OR/M tools. Also, it associates design patterns with architectural decisions in a less rigid way than your classical pattern book.
I totally digged the Data Access Layer chapter.
The only thing that I struggled a little was the language: many times I felt like the concepts could have been expressed with significantly less words and maybe more examples. In fact, I often got bored and had to take a break and come back the day after.
Other than that, it's one of the best texts I've read in a while.


Merlin
17 December, 2009

Excellent book

This book is well written and structured in a very intuitive way. It starts with a general and informative discussion of software architecture and then proceeds to take a detailed look at the various design decisions, patterns and components that can be found in a layered design. It references and elaborates upon many of the patterns in Martin Fowler's Patterns of Enterprise Application Architecture so a familiarity with that work is recommended but not necessarily required. It can both act as a supplement to the PoEAA in addition to standing very well on its own.

This book is required reading and highly recommended.

Adam Garren
17 November, 2009

Great Book

This is a great book. Microsft has never been very good at guiding developers and software architects for building complex systems. I think this books fills that gap. Dino Esposito is one of the best .NET writers and he shows that in this book.
The book is very well structured and easy to read. The first part is about principles and best practices of software architecture, design and developement (UML, the role of an enterprise architect, OOP).
The second part covers each layer of an enterprise application: Business Layer, Service Layer, Data Access Layer and UI Layer. It covers the most important patterns presented in Martin Fowler's book Patterns of Enterprise Application Architecture. Some of them are:
-BL:
Transaction Script
Table Module
Domain Model
Active Record (Although Fowler categorizes this pattern as a DAL)
-Service Layer:
Service Layer
DTO
-DAL:
Plugin
Inversion of Control
Lazy Loading,
Identity Map
Data Mapper
Unit Of Work
-UI:
MVC
MVP
PM
Front Controller
There's also a sample application that shows all the patterns and practices covered in the book.

Alan Macgowan
29 September, 2009

Mustknown material for the .NET architect, nicely gathered within this book

Full of known material for the experienced .NET architect, but even then useful for confirmation and reference.

W. J. M. Strien
14 September, 2009

Great book

Part 1 (1st 3 chapters) is kinda boring to read if you have been doing software design for years.
Fortunately, Part 2 is extremely excellent, useful and practical to the .NET development environment.

I will recommend this book to all .NET developers.


Steven Koh
11 September, 2009

I ordered a copy for each of my developers

I was reading Dinos and Andrea's book during my holydays in Italy. It is one of the best books I read in the last few months. I'm especially pleased, that this book brings the concepts and patterns from Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software, which I by the way read during my holydays last year, and Martin Fowler Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) closer to the developers. I'm running a small software production company (see YouTube enventionag) and I just ordered 13 copies of this great book to get each of my developers a personal copy.

Anton Kaufmann
28 July, 2009

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.

P. C. Mehta
04 June, 2009

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.

S. H. Polen
04 May, 2009

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

regards,

Alexander Koval (http://www.grandmasterit.com)

Alexander Koval
29 April, 2009

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.


David M. Davis
14 April, 2009

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.]

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. ---]]



Daylight
09 April, 2009

What a Microsoft Solutions, Enterprise, and Other Architects Should Know Today

This is a well structured book with what I think maintains a good depth and breadth of both general software construction topics and Microsoft technologies for all different types of software architects. The authors touched on all the topics I expected based on the book's title and then some. Expected prerequisites for the book include strong object-oriented (OO) programming and a good foundation of .NET platform knowledge and data access techniques.

The authors have put a lot of effort into "...making this book read well" and I can tell. It seems a lot of the time was spent not only getting the right content into the book but carefully crafting of the content so the reader isn't wasting his time fumbling through the material.

An interesting topic I found was in Chapter 5 (The Service Layer) of this book that includes a discussion on the Data Transfer Object pattern vs. Domain Model pattern. Our development team has run into this very debate. There are tradeoffs with each extreme and I think the authors do a great job bringing out some excellent of points of debate.

I enjoy the book's "Note" blocks that add quick side notes to the current topic including more information, online information, and a higher level overview of the current topic. I found this last type of side note very helpful since the details can begin to get a bit overwhelming and the note brings back a sense of overall direction with the topic.

I also like the OO perspective that the authors use. Discussions involve an object's responsibility, knowledge, or behavior. Other great topics include: Tenets of SOA, Structured Design, Separation of Concerns, and OO Design Principles such as The Open/Closed Principle, Liskov's Substitution Principle, and the Dependency Inversion Principle.

Overall the book is enjoyable to read. A lot of great topics on designing software architecture are covered. It gives a great snapshot of what a Microsoft Solutions, Enterprise, and other architects should know today with plenty of online references to dig deeper into some of the topics.

Full Disclosure: This book was given to me in trade for my review.

Originally published by the Denver Visual Studio User Group at [...] February, 2009.

Richard Ruge
03 April, 2009

A must for any .net senior developer or .net architect

In the era of online documentation, this is one of the few technical books that I read from end to end. Thoroughly enjoyed it while occassionally referring to Martin Fowler's P of EAA book. However you can read this book whether you read Fowler's book or not. You may also want to combine the knowledge from this book with Nilsson's Applying Domain-Driven Design and Patterns book.

Raghu Rudra
14 March, 2009

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:
Modularity
Information Hiding
Separation of Concerns
Cohesion
Business Objects vs Domain Objects
Liskov's Substitution Principle
Dependency Inversion Principle
Dependency Injection and Inversion of Controls
Antipatterns
Mocks
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..

rafal buch
19 January, 2009

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.

Oleksandr Novosad
14 January, 2009

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.



K. Frost
05 January, 2009

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.

Bud Arch
05 January, 2009

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 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.


James Ashley
01 January, 2009

Nice book, here is the Table of Contents

This book seemed really promising from the title and mainly its author (Dino Esposito), who is one of the best .NET writers out there. It took me a while to buy it though, because for weeks I tried in vain to find its table of contents, to know exactly what I was buying. Having failed at finding one, I decided to just take a chance and buy it anyway, and I don't regret, it is a good book.

I would say the target audience is intermediate to senior developers who are getting into software architecture, or architects who work on a database-centric way and want to get an update to the current buzzwords, such as domain model pattern, repositories, services, AOP, POCO, OR/M, DDD etc. This book does not try to be a definitive source on any of those topics, but more like an introduction and a reference; the authors make a good job at pointing for resources for those who want to get more dense information.

Books like Martin Fowler's "Patterns of Enterprise Application Architecture", the GoF classic Design Patterns book and Eric Evan's "Domain-Driven Design" are mentioned dozens of times, so people who have already read those books may not have lots of new stuff to see here, unless they are looking for a lighter reference or want to see how some of those ideas can be applied on .NET.

So, for those like me who have spent a few days on Google trying to find out the book's ToC, here is a summarized version, with some of the topics covered in parenthesis:

Part 1 - Principles

1 - Architects and Architecture Today (software life cycle, agile methodologies etc)
2 - UML essentials (UML models and usage, use-case diagrams, class diagrams, sequence diagrams)
3 - Design Principles and Practices (OOD, AOP)

Part 2 - Design of the System

4 - The business layer (transaction script pattern, table module pattern, active record pattern, domain model pattern, DDD)
5 - The service layer (service layer pattern, remote façade pattern, adapter pattern, SOA, AJAX service layer for rich web frontends)
6 - The data access layer (plugin pattern, Inversion of Control, data context, query services, concurrency, lazy loading, OR/M, stored procedures, dynamic SQL)
7 - The presentation layer (MVC, MVP, presentation model pattern, choosing a UI pattern, MVP in web presentations, MVP in Windows presentations)

8 - Final thoughts






Lerxst
23 December, 2008

Great book overall

I wish my team would read this book. Too many developers in the workforce right now do not understand these principles, and should.

The book does a great job of putting the whole package together and how to implement each layer.

I would write a lot more if I was not so busy. I can't say enough.

Who should get this? Anyone that has already learned the fundumentals of developing in .NET.

Kelly D. Rupp
13 December, 2008

This book will not leave my side... until the 2nd edition...

This book does a great job of putting architecture into a view that .NET developers and architects can relate to.

The book covers design principles and patterns, and then relates them to each layer of a traditional layered system. It includes business, services, data access, and presentation layers. The authors include several different patterns for each layer and discuss the pros and cons of each.

The book focuses on the technical aspects of .NET architecture. It does not cover the soft skills need to be an architect, or cover the customer facing skills need to communicate with the business stakeholders. You won't find much on process either, just an overview. These missing topics have not taken away from the book, they have made it a stronger book. There are plenty of resources on how to execute the soft skills and architecture process. This book concentrates on how to communicate with the development team through solid design and well known patterns and principles.

This is a must read for all architects, no matter what your skill set is.

A .NET developer looking to move into architecture should make this book their first stop on a long journey. This will definitely get you off to a very strong start.

This book will not leave my side... until the 2nd edition...

T. Anderson
04 December, 2008

Fun to read, great recap

I back ordered this item as soon as I saw it on my amazon suggestions. I had read books from Dino Esposito before and like the way he presents the concepts. The book is fun to read and inspirational. The UML recap is very handy. The section To SP or not to SP in chapter 6 a is a must read, I will definitely pass that on to some coworkers! Finally a great good summary of reasons why stored procedures are not the silver bullet.
The organization of the book in patterns per application layer is also a very good way to present the information, must software pattern books give a summary of patterns without emphasizing where it would be better to apply the pattern itself, or the pattern components.


Lizet Pena de Sola
21 November, 2008