.NET软件架构之美(英文影印版)（.NET软件架构设计圣经）
点击看大图基本信息
- 作者： (意)Dino Esposito Andrea Saltarello [作译者介绍]
- 丛书名： 图灵程序设计丛书 C#与.NET系列
- 出版社：人民邮电出版社
- ISBN：9787115200181
- 上架时间：2009-9-11
- 出版日期：2009 年9月
- 开本：16开
- 页码：433
- 版次：1-1
- 所属分类：
计算机 > 软件与程序设计 > .NET > 框架设计
编辑推荐
.NET软件架构设计圣经.
Amazon全五星图书..
紧贴实战，透过实例探讨架构设计最佳实践
深刻阐述软件开发思想...
推荐阅读
内容简介回到顶部↑
书籍
计算机书籍
软件架构设计是现代软件开发的核心，它不仅是一门技术，更是一门艺术。然而，长期以来，一直没有一本讲述.net架构设计的书。.
本书填补了这一缺憾。两位作者人选可谓众望所归，他们将gof设计模式、martin fowler企业架构模式、eric evans领域驱动设计等业界精华与自己多年软件开发实战经验结合起来，深刻阐述了软件架构设计思想精髓。作者还从技术架构角度逐章讲述了业务层、服务层、数据访问层和表现层的分层设计，同时介绍了各种软件架构设计方案的优与劣，如何在各种方案中做出抉择，以及如何将这些设计原则更具体地应用到应用程序中。..
本书出自两位具有多年软件开发经验的 asp .net专家、作者和培训师之手，内容涉及多层架构、设计模式以及设计原则。第一部分简要介绍 uml、设计原则及模式；第二部分从技术架构角度讨论分层设计。本书行文流畅，语言通俗易懂，阐述了各种架构设计技术方案的优与劣，并讲述了如何在优与劣中做出权衡。中设计了真实的场景，展示了如何将这些设计原则更加具体地应用到 .net应用程序中。
本书适合各层次 .net开发人员阅读。...
计算机书籍
软件架构设计是现代软件开发的核心，它不仅是一门技术，更是一门艺术。然而，长期以来，一直没有一本讲述.net架构设计的书。.
本书填补了这一缺憾。两位作者人选可谓众望所归，他们将gof设计模式、martin fowler企业架构模式、eric evans领域驱动设计等业界精华与自己多年软件开发实战经验结合起来，深刻阐述了软件架构设计思想精髓。作者还从技术架构角度逐章讲述了业务层、服务层、数据访问层和表现层的分层设计，同时介绍了各种软件架构设计方案的优与劣，如何在各种方案中做出抉择，以及如何将这些设计原则更具体地应用到应用程序中。..
本书出自两位具有多年软件开发经验的 asp .net专家、作者和培训师之手，内容涉及多层架构、设计模式以及设计原则。第一部分简要介绍 uml、设计原则及模式；第二部分从技术架构角度讨论分层设计。本书行文流畅，语言通俗易懂，阐述了各种架构设计技术方案的优与劣，并讲述了如何在优与劣中做出权衡。中设计了真实的场景，展示了如何将这些设计原则更加具体地应用到 .net应用程序中。
本书适合各层次 .net开发人员阅读。...
作译者回到顶部↑
本书提供作译者介绍
Dino Esposito .NET和软件架构技术方面的世界权威，微软ASP.NET MVP。目前就职于著名的.NET技术咨询公司IDesign。他是广受欢迎的技术作家，担任MSDN Magazine特邀专栏作家多年，并撰有Programming ASP.NET 3.5 Core References等名著。.
Andrea Saltarello 微软ASP.NET MVP，意大利.NET用户组负责人。现任Managed Designs公司首席软件架构师。...
.. << 查看详细
Andrea Saltarello 微软ASP.NET MVP，意大利.NET用户组负责人。现任Managed Designs公司首席软件架构师。...
.. << 查看详细
目录回到顶部↑
part i principles.
1 architects and architecture today 3
what's a software architecture, anyway? 4
applying architectural principles to software 4
what's architecture and what's not 8
architecture is about decisions 10
requirements and quality of software 12
who's the architect, anyway? 17
an architect's responsibilities 17
how many types of architects do you know? 20
common misconceptions about architects 21
overview of the software development process 24
the software life cycle 24
models for software development 26
summary 30
murphy's laws of the chapter 30
2 uml essentials 31
uml at a glance 32
motivation for and history of modeling languages 33
uml modes and usage 36
1 architects and architecture today 3
what's a software architecture, anyway? 4
applying architectural principles to software 4
what's architecture and what's not 8
architecture is about decisions 10
requirements and quality of software 12
who's the architect, anyway? 17
an architect's responsibilities 17
how many types of architects do you know? 20
common misconceptions about architects 21
overview of the software development process 24
the software life cycle 24
models for software development 26
summary 30
murphy's laws of the chapter 30
2 uml essentials 31
uml at a glance 32
motivation for and history of modeling languages 33
uml modes and usage 36
前言回到顶部↑
Introduction .
Good judgment comes from experience, and experience comes from bad judgment.
—Fred Brooks
Every time we are engaged on a software project, we create a solution. We call the process architecting, and the resulting concrete artifact is the architecture. Architecture can be implicit or explicit.
An implicit architecture is the design of the solution we create mentally and persist on a bunch of Microsoft Offi ce Word documents, when not on handwritten notes. An implicit architecture is the fruit of hands-on experience, the reuse of tricks learned while working on similar projects, and an inherent ability to form abstract concepts and factor them into the project at hand. If you’re an expert artisan, you don’t need complex drawings and measurements to build a fence or a bed for your dog; you can implicitly architect it in a few moments. You just proceed and easily make the correct decision at each crossroad. When you come to an end, it’s fi ne. All’s well that ends well.
An explicit architecture is necessary when the stakeholder concerns are too complex and sophisticated to be handled based only on experience and mental processes. In this case, you need vision, you need guidance, and you need to apply patterns and practices that, by design, take you where you need to be.
What Is Architecture?
The word architecture has widespread use in a variety of contexts. You can get a defi nition for it from the Oxford English Dictionary or, as far as software is concerned, from the American National Standards Institute/Institute of Electrical and Electronics Engineers (ANSI/IEEE) library of standards. In both cases, the defi nition of architecture revolves around planning, designing, and constructing something—be it a building or a software program. Software architecture is the concrete artifact that solves specifi c stakeholder concerns—read, specifi c user requirements.
An architecture doesn’t exist outside of a context. To design a software system, you need to understand how the fi nal system relates to, and is embedded into, the hosting environment. As a software architect, you can’t ignore technologies and development techniques for the environment of choice—for this book, the .NET platform.
Again, what is architecture?
We like to summarize it as the art of making hard-to-change decisions correctly. The architecture is the skeleton of a system, the set of pillars that sustain the whole construction. A08I562096.indd xvii 9/22/2008 3:34:56 PM
xviii Introduction
The architect is responsible for the architecture. The architect’s job is multifaceted. She has to acknowledge requirements, design the system, ensure the implementation matches the expectation, and overall ensure that users get what they really need—which is not necessarily what they initially accept and pay for.
Software architecture has some preconditions—that is, design principles—and one post condition—an implemented system that produces expected results. Subsequently, this book is divided into two parts: principles and the design of the system.
The fi rst part focuses on the role of the architect: what he does, who he interacts with and who he reports to. The architect is primarily responsible for acknowledging the requirements, designing the system, and communicating that design to the development team. The communication often is based on Unifi ed Modeling Language (UML) sketches; less often, it’s based on UML blueprints. The architect applies general software engineering principles fi rst, and object-oriented design principles later, to break down the system into smaller and smaller pieces in an attempt to separate what is architecture (points that are hard to change) and what is not. One of the purposes of object-oriented design is to make your code easy to maintain and evolve—and easy to read and understand. The architect knows that maintainability, security, and testability need to be built into the system right from the beginning, and so he does that.
The second part of the book focuses on the layers that form a typical enterprise system—the presentation layer, business layer, and data access layer. The book discusses design patternsfor the various layers—including Domain Model, Model-View-Presenter, and Service Layer—and arguments about the evolution of technologies and summaries of the new wave of tools that have become a common presence in software projects—O/R mappers and dependency injection containers.
So, in the end, what’s this book about?
It’s about the things you need to do and know to serve your customers in the best possible way as far as the .NET platform is concerned. Patterns, principles, and techniques described in the book are valid in general and are not specifi c to particularly complex line-of-business applications. A good software architecture helps in controlling the complexity of the project.
And controlling the complexity and favoring maintainability are the sharpest tools we have to fi ght the canonical Murphy’s Law of technology: “Nothing ever gets built on schedule or within budget.”
The expert is the one who knows how to handle complexity, not the one who simply predicts the job will take the longest and cost the most—just to paraphrase yet another popular Murphy’s Law.
Good judgment comes from experience, and experience comes from bad judgment.
—Fred Brooks
Every time we are engaged on a software project, we create a solution. We call the process architecting, and the resulting concrete artifact is the architecture. Architecture can be implicit or explicit.
An implicit architecture is the design of the solution we create mentally and persist on a bunch of Microsoft Offi ce Word documents, when not on handwritten notes. An implicit architecture is the fruit of hands-on experience, the reuse of tricks learned while working on similar projects, and an inherent ability to form abstract concepts and factor them into the project at hand. If you’re an expert artisan, you don’t need complex drawings and measurements to build a fence or a bed for your dog; you can implicitly architect it in a few moments. You just proceed and easily make the correct decision at each crossroad. When you come to an end, it’s fi ne. All’s well that ends well.
An explicit architecture is necessary when the stakeholder concerns are too complex and sophisticated to be handled based only on experience and mental processes. In this case, you need vision, you need guidance, and you need to apply patterns and practices that, by design, take you where you need to be.
What Is Architecture?
The word architecture has widespread use in a variety of contexts. You can get a defi nition for it from the Oxford English Dictionary or, as far as software is concerned, from the American National Standards Institute/Institute of Electrical and Electronics Engineers (ANSI/IEEE) library of standards. In both cases, the defi nition of architecture revolves around planning, designing, and constructing something—be it a building or a software program. Software architecture is the concrete artifact that solves specifi c stakeholder concerns—read, specifi c user requirements.
An architecture doesn’t exist outside of a context. To design a software system, you need to understand how the fi nal system relates to, and is embedded into, the hosting environment. As a software architect, you can’t ignore technologies and development techniques for the environment of choice—for this book, the .NET platform.
Again, what is architecture?
We like to summarize it as the art of making hard-to-change decisions correctly. The architecture is the skeleton of a system, the set of pillars that sustain the whole construction. A08I562096.indd xvii 9/22/2008 3:34:56 PM
xviii Introduction
The architect is responsible for the architecture. The architect’s job is multifaceted. She has to acknowledge requirements, design the system, ensure the implementation matches the expectation, and overall ensure that users get what they really need—which is not necessarily what they initially accept and pay for.
Software architecture has some preconditions—that is, design principles—and one post condition—an implemented system that produces expected results. Subsequently, this book is divided into two parts: principles and the design of the system.
The fi rst part focuses on the role of the architect: what he does, who he interacts with and who he reports to. The architect is primarily responsible for acknowledging the requirements, designing the system, and communicating that design to the development team. The communication often is based on Unifi ed Modeling Language (UML) sketches; less often, it’s based on UML blueprints. The architect applies general software engineering principles fi rst, and object-oriented design principles later, to break down the system into smaller and smaller pieces in an attempt to separate what is architecture (points that are hard to change) and what is not. One of the purposes of object-oriented design is to make your code easy to maintain and evolve—and easy to read and understand. The architect knows that maintainability, security, and testability need to be built into the system right from the beginning, and so he does that.
The second part of the book focuses on the layers that form a typical enterprise system—the presentation layer, business layer, and data access layer. The book discusses design patternsfor the various layers—including Domain Model, Model-View-Presenter, and Service Layer—and arguments about the evolution of technologies and summaries of the new wave of tools that have become a common presence in software projects—O/R mappers and dependency injection containers.
So, in the end, what’s this book about?
It’s about the things you need to do and know to serve your customers in the best possible way as far as the .NET platform is concerned. Patterns, principles, and techniques described in the book are valid in general and are not specifi c to particularly complex line-of-business applications. A good software architecture helps in controlling the complexity of the project.
And controlling the complexity and favoring maintainability are the sharpest tools we have to fi ght the canonical Murphy’s Law of technology: “Nothing ever gets built on schedule or within budget.”
The expert is the one who knows how to handle complexity, not the one who simply predicts the job will take the longest and cost the most—just to paraphrase yet another popular Murphy’s Law.
媒体评论回到顶部↑
“所有架构师的必读之作……无可替代。”.
——.NET Developer’s Journal
“还等什么？如果你有机会看到本书，请尽快把它 ‘消灭’，就像我在地铁上如饥似渴地畅读一样……”..
——王涛（AnyTao），微软MVP
“本书酣畅淋漓地阐发了.NET平台下企业软件架构的精髓，为开发人员献上了不可多得的饕餮大餐。”
——陈黎夫（Dflying），微软MVP...
——.NET Developer’s Journal
“还等什么？如果你有机会看到本书，请尽快把它 ‘消灭’，就像我在地铁上如饥似渴地畅读一样……”..
——王涛（AnyTao），微软MVP
“本书酣畅淋漓地阐发了.NET平台下企业软件架构的精髓，为开发人员献上了不可多得的饕餮大餐。”
——陈黎夫（Dflying），微软MVP...
)
加载中...
