.NET软件架构之美

2009年9  

人民邮电出版社  

Dino Esposito,Andrea Saltarello  

432  

547000  

无  

　　本书出自两位具有多年软件开发经验的 ASP .NET专家、作者和培训师之手，内容涉及多层架构、设计模式以及设计原则。第一部分简要介绍 UML、设计原则及模式；第二部分从技术架构角度讨论分层设计。本书行文流畅，语言通俗易懂，阐述了各种架构设计技术方案的优与劣，并讲述了如何在优与劣中做出权衡。中设计了真实的场景，展示了如何将这些设计原则更加具体地应用到 .NET应用程序中。　　本书适合各层次 .NET开发人员阅读。

作者：(意大利)埃斯波西托(Dino Esposito) (意大利)索尔塔雷罗(Andrea Saltarello)DinoEsposito，．NET和软件架构技术方面的世界级权威，微软ASP．NETMVP。目前就职于著名的．NET技术咨询公司IDesign。他是广受欢迎的技术作家。担任MSDNMagazine特邀专栏作家多年。并撰有ProgrammingASP．NET-3．5CoreReferences等名著。AndreaSaItareIIo，微软ASP．NETMVP。意大利．NET用户组负责人。现任ManagedDesigns公司首席软件架构师。

Part I　Principles　1　Architects and Architecture Today　　　 What's a Software Architecture, Anyway?　　　　Applying Architectural Principles to Software　　　　What's Architecture and What's Not　　　　Architecture Is About Decisions　　　　Requirements and Quality of Software　　　 Who's the Architect, Anyway?　　　　An Architect's Responsibilities　　　　How Many Types of Architects Do You Know?　　　　Common Misconceptions About Architects　　　 Overview of the Software Development Process　　　　The Software Life Cycle　　　　Models for Software Development　　　 Summary　　　 Murphy's Laws of the Chapter　　2　UML Essentials　　　 UML at a Glance　　　　Motivation for and History of Modeling Languages　　　　UML Modes and Usage　　　 UML Diagrams　　　　Use-Case Diagrams　　　　Class Diagrams　　　　Sequence Diagrams　　　 Summary　　　 Murphy's Laws of the Chapter　　3　Design Principles and Patterns　　　 Basic Design Principles　　　　For What the Alarm Bell Should Ring　　　　Structured Design　　　　Separation of Concerns　　　 Object-Oriented Design　　　　Basic OOD Principles　　　　Advanced Principles　　　 From Principles to Patterns　　　　What's a Pattern, Anyway?　　　　Patterns vs. Idioms　　　　Dependency Injection　　　 Applying Requirements by Design　　　　Testability　　　　Security　　　 From Objects to Aspects　　　　Aspect-Oriented Programming　　　　AOP in Action　　　 Summary　　　 Murphy's Laws of the Chapter　Part II　Design of the System　4　The Business Layer　　　 What's the Business Logic Layer, Anyway?　　　　Dissecting the Business Layer　　　　Where Would You Fit the BLL?　　　　Business and Other Layers　　　　Patterns for Creating the Business Layer　　　 The Transaction Script Pattern　　　　Generalities of the TS Pattern　　　　The Pattern in Action　　　 The Table Module Pattern　　　　Generalities of the TM Pattern　　　　The TM Pattern in Action　　　 The Active Record Pattern　　　　Generalities of the AR Pattern　　　　The AR Pattern in Action　　　 The Domain Model Pattern　　　　Generalities of the DM Pattern　　　　The DM Pattern in Action　　　 Summary　　　 Murphy's Laws of the Chapter　　5　The Service Layer　　　 What's the Service Layer, Anyway?　　　　Responsibilities of the Service Layer　　　　What's a Service, Anyway?　　　　Services in the Service Layer　　　 The Service Layer Pattern in Action　　　　Generalities of the Service Layer Pattern　　　　The Service Layer Pattern in Action　　　 Related Patterns　　　　The Remote Fa?ade Pattern　　　　The Data Transfer Object Pattern　　　　The Adapter Pattern　　　　DTO vs. Assembly　　　 Service-Oriented Architecture　　　　Tenets of SOA　　　　What SOA Is Not　　　　SOA and the Service Layer　　　 The Very Special Case of Rich Web Front Ends　　　　Refactoring the Service Layer　　　　Designing an AJAX Service Layer　　　　Securing the AJAX Service Layer　　　 Summary　　　 Murphy's Laws of the Chapter　　6　The Data Access Layer　　　 What's the Data Access Layer, Anyway?　　　　Functional Requirements of the Data Access Layer　　　　Responsibilities of the Data Access Layer　　　　The Data Access Layer and Other Layers　　　 Designing Your Own Data Access Layer　　　　The Contract of the DAL　　　　The Plugin Pattern　　　　The Inversion of Control Pattern　　　　Laying the Groundwork for a Data Context　　　 Crafting Your Own Data Access Layer　　　　Implementing the Persistence Layer　　　　Implementing Query Services　　　　Implementing Transactional Semantics　　　　Implementing Uniquing and Identity Maps　　　　Implementing Concurrency　　　　Implementing Lazy Loading　　　 Power to the DAL with an O/RM Tool　　　　Object/Relational Mappers　　　　Using an O/RM Tool to Build a DAL　　　 To SP or Not to SP　　　　About Myths and Stored Procedures　　　　What About Dynamic SQL?　　　 Summary　　　 Murphy's Laws of the Chapter　　7　The Presentation Layer　　　 User Interface and Presentation Logic　　　　Responsibilities of the Presentation Layer　　　　Responsibilities of the User Interface　　　　Common Pitfalls of a Presentation Layer　　　 Evolution of the Presentation Patterns　　　　The Model-View-Controller Pattern　　　　The Model-View-Presenter Pattern　　　　The Presentation Model Pattern　　　　Choosing a Pattern for the User Interface　　　 Design of the Presentation　　　　What Data Is Displayed in the View?　　　　Processing User Actions　　　 Idiomatic Presentation Design　　　　MVP in Web Presentations　　　　MVP in Windows Presentations　　　 Summary　　　 Murphy's Laws of the Chapter　　Final Thoughts　　Appendix: The Northwind Starter Kit　Index　

插图：To design a system——any system in any scientific field——you first need to create an abstractionof it. An abstraction is essentially a model that provides a conceptual representation of thesystem in terms of views, structure, behavior, participating entities, and processes.A model exists to be shared among the stakeholders of the system, including developers,architects, owners, and customers. Stakeholders should be able to understand the model inorder to provide feedback, spot wrong assumptions, and suggest improvements. To share amodel, though, you need to express it in a formal way using a common, and possibly broadlyaccepted, notation. For this, you need a modeling language.Typically, a modeling language is a graphical or textual language based on a set of rules,symbols, diagrams, and keywords. All together, the language elements are used to expressthe structure and behavior of the model in a way that transmits clear knowledge andinformation to anybody familiar with the language.There are several well-known examples of modeling languages——for exampe the IntegratedDEFinition （IDEF） family of modeling languages used for functional modeling, informationmodeling, simulation, and more. There's also the VirtuaIReality Modeling Language （VRML）,which is used to represent 3D graphics, and EXPRESS （textual） and EXPRESS-G （graphical） fordata modeling.However, when it comes to modeling languages, the most popular one is Unified ModelingLanguage （UML）. UML is a general-purpose graphical modeling language that, over theyears, has become the industry standard for modeling software systems. Based on a family ofgraphical notations, UML is particularly suited to creating models in obJect-oriented scenarios.It might not be as effective when another paradigm is used, such as a functional or perhapsa relational paradigm, but it's a good fit for object-oriented systems.

“所有架构师的必读之作……无可替代。”　　——．NET Developer's Journal“还等什么？如果你有机会看到本书，请尽快把它‘消灭’。就像我在地铁上如饥似渴地畅读一样……”　　——王涛（AnyTao）。微软MVP“本书酣畅淋漓地阐发了．NET平台下企业软件架构的精髓。为开发人员献上了不可多得的饕餮大餐。”　　——陈黎夫（Dflying），微软MVP

《.NET软件架构之美(英文版)》填补了这一缺憾。两位作者人选可谓众望所归，他们将GoF设计模式、MartinFowler企业架构模式、EricEvans领域驱动设计等业界精华与自己多年软件开发实战经验结合起来，深刻阐述了软件架构设计思想精髓。作者还从技术架构角度逐章讲述了业务层、服务层、数据访问层和表现层的分层设计，同时介绍了各种软件架构设计方案的优劣，如何在各种方案中做出抉择，以及如何将这些设计原则更具体地用到应用程序中。软件架构设计是现代软件开发的核心，它不仅是一门技术，更是一门艺术。然而，长期以来，还没有一本专门讲述.NET架构设计的书。Amazon全五星图书，紧贴实战，透过实例探讨架构设计最佳实践，深刻阐述软件开发思想。

无

.NET软件架构之美 PDF格式下载

****软件架构之美，好书。

非常经典的一本设计书籍，但是不适合初学者。
而且在工作中也可以用到，非常好。

其实今年读了许多好书，不过有不少都是以前看过的，唯有这本，花了我很多时间去研究（本人英语虽不算差，但是阅读速度肯定低于中文）。除了工作和睡觉，一有机会就翻看。其他的等看完后继续补充。

蛮好，感觉不错

结合作者自己的理解，对对前人知识的总结，主要着眼于设计模式

出自大师之笔，自然还不错，所以好的方面就不在多说。
但是书的质量太差，整本书很轻，还有难闻的味道。非常怀疑不是正版的。
内容方法讲的也不是很详细

写的很简练，值得一读！

对于不是很了解企业应用设计模式与架构思想，可以通过本书了解一些基本的概念、理论和最佳实践，不过你是一个资深的架构师，相信对于里面觉得部分内容你都不会感到模式。所以，这是一本讲我们熟知的设计模式和架构思想进行汇总的书，如果你想深入理解其精髓，我觉得最好还是看看MartinFowler的《PatternsofEnterpriseApplicationArchitec***e》，J.DMeier的《patterns&practicesApplicationArchitec***eBook》也值得一荐！

英语不过关的，别买；不是做****的也别买！

这本书我基本上看完了，印刷质量还不错。书写得也很好。最好是有一定的.net相关经验的人来看。另外，书中非常多的地方引用到了《企业应用架构模式》（Martin Fowler）。可以先看下这本，当然，就算没看这本书也基本不妨碍阅读。

有参考价值，能解答很多疑惑

书页质量还不错，内容还没看

很值得花时间反复读的书，建议所有想完善架构方面知识的人都读读。你会在理论和实践中都有提高，并且此书的英文用比较平实的语句，也相对好理解。

还不错 正在研读中

终于还是在上周把这本书啃完了，差不多两个月的时间。绝对是本好书，它让你从一个更高的视觉去审视和构建企业类软件。还是再看一遍。。。。

内容不错,看的速度比较慢,三天了才看完第一章.

清晰，实用，全面

还没看完，感觉还没到那个高度，等过段时间再回去看。

深入剖析，不仅仅是介绍How，更多的是解释Why！

效率真高，这么快就有影印版了，等得就是这本！经典，估计很快就要被抢空了。。。