代Web开现发：理解领域、技术和使用者体验外文翻译资料

英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料

译文

代Web开现发：理解领域、技术和使用者体验

第一章.进行一个完全的领域分析

越来越多的开发人员和管理人员似乎都认为现在编写软件越来越难了。就我自己而言，软件项目有时候会失败，超出了分配的预算或者当事情没有变得太坏的时候，只迟了几个星期就进入了生产阶段。我想知道为什么发展的项目会以这种方式令人失望，我看了一些问题的答案，但我还是不能确定并且自信的去分享。

当我很难理解事情的机制的时候，我会试着回头看看我走过的步骤以及那些导致当前情况的步骤。在我生活中的某些点，我是个学习开车和停车的青少年，有一天，我的父亲挑战我，让我把车开出来从他停的那个小地方里。“这是不可能的”我说。在20分钟不成功的错误之后，他说：“你错了”并且耐心的解释他在停车时的动作。这件事件说明：如果有办法把它拖到场地，就有办法再把它拖出来。所以本章节想要回答的问题是：我们应该做些什么将编写程序的过程变成可靠的成功的过程，我相信我们必须改变我们现在对软件的看法并且继续改变设计软件的方法。软件在我们的社会和商业生活中越来越普遍，因此，软件更被期望可以反映社会和商业过程而不是相近的分散模型，但是建模是当前这一代软件架构师成长的过程。根本上，编写软件是不难的。尤其是当你停止建模并且计划它来反映你现实中看到的东西。在当今世界中，软件的价值增长只有在它遇到真正的需求并且简化业务过程时。软件并不一定与设计新的业务流程有关——在业务流程管理上(BPM)它有特定的方法。可代替的是，软件是关于真实世界的各个部分的真实建模。这些部分实际上被称为商业领域。在需求分析过程中，你可能会发现一些概念遮盖了业务流程的边界。例如，相同的术语可能用来表示不同的东西，并代表不同的过程。

第二章.WEB解决方案的架构选项

很明显，现在开发软件时，比了解技术更重要的是知道如何做具体的事情。这意味着学习设计和架构模式、最佳实践、支持架构、以及有成功记录的应用解决方案。越来越多的软件正在与商业相融合，仅仅了解技术是不足以解决现实世界中的问题的。现实世界的业务解决方案往往来自于多种、甚至异构技术的组合。所以，如果你不进行仔细的分析，你就哪儿也去不了，至少不能按时完成，也没有预算。

你可以通过技术来完成具体的软件工作，但是现在仅仅升级一项技术已不再是成功的保证。当然，曾经有一段时间，只要升级到最新的数据库管理系统(DBMS)、操作系统或库就能神奇地解决任何悬而未决的问题。这些天，软件对用户来说越有意义，它就越能捕捉到真实世界的过程。是时候让建筑师们学会镜像，而不是模仿现实世界了。在这一章中，我将研究一些你在设计web解决方案时的选择。我将根据新的微软来做这个，ASP.NET Core 1.0框架和相关的运行时管道。

第三章.分层架构计算机程序

成为单片软件的产物已经有好几年了。单片软件是一种端到端的程序指令序列，实现目标虽然现在几乎没有专业的开发人员或架构师会认真考虑编写端到端程序，但对于新手来说，构建庞然大物是进行软件开发的最自然的方式。每一片单块并不坏，重要的是程序是否实现了它的使命，但随着程序的复杂性的增加，单块的作用越来越小。因此，在现实世界的软件体系结构中，整体是不合适的。几十年来，它们一直不受欢迎。在软件中，在已知的接口后面隐藏了一组给定功能的实现细节。层服务于关注点分离的目的，并促进同一系统中不同组件之间的交互性。在面向对象系统中，层本质上是一组实现给定业务目标的类。不同的层可以部署到物理层，有时以服务或微服务的形式，在已知的网络协议(如HTTP)上发挥作用。层是指与其他层共存的一段软件。层是指组件之间的逻辑分离，而不是物理分离。我在本章中介绍的层架构可能是最被广泛接受的混合功能和业务以产生一个工作系统的方法。除了经典的三层系统之外，您可能从小就有这样的想法，即任何软件系统都应该安排在三层分段:表示层、业务层和数据层。演示部分由屏幕(桌面、移动或web界面)组成，用于收集输入数据并演示结果。数据段是处理数据库、保存和读取信息的地方。业务部门是你需要拥有的一切的地方。

三层体系结构已经存在很长时间了，但它起源于大多数业务工作要么与数据库相关，要么限于外部组件(如大型机)的时代。在大多数情况下，三层体系结构使用单一的数据模型，从数据存储到表示并返回。体系结构当然不会阻止您使用其他类型的数据传输对象，但是在大多数情况下，三层体系结构只是模型的象征，并且是以数据库为中心的。这些领域驱动设计(DDD)预见到的挑战是如何将持久性与表示需求相匹配。尽管任何系统的核心操作仍然是创建-读取-更新-删除(CRUD)，但业务规则影响这些核心操作的方式需要业务层处理太多的数据转换和太多的流程编排。尽管许多教程坚持将电子商务平台描述为一个关于客户和订单的普通CRUD，但现实情况却并非如此。你永远不会只向数据库添加一个订单记录。订单的用户界面和订单表的模式之间永远不会只有一对一的匹配。最可能的情况是，在表示级别上，您甚至没有对顺序的感知。您更可能拥有购物车之类的东西，一旦处理，就会在某些数据库表中生成订单记录。在三层思维模型中，业务流程是最难组织的部分。业务流程不仅仅是软件中最重要的东西:它们是唯一真正重要的东西，是不可能妥协的东西。乍一看，业务流程是业务层的核心。然而，通常情况下，业务流程的范围太广，不容易被限制在喜欢的体系结构范围内可以很容易地变成物理层。不同的表示层可以触发不同的业务流程，不同的业务流程可以引用相同的核心行为和一些规则的实现。尽管业务逻辑的含义似乎很明显，但业务逻辑可重用部分的正确粒度却一点也不明显。

第四章ASP.NET的最新技术

在第二章“网络解决方案的架构选择”中，我列出并讨论了我们今天在网络解决方案的架构和构建方面的选择。如果你正在寻找具体的建议和用例，你可以回到那一章，并可能完全跳过这一章。这一章的目的是介绍下一章以及下一章之后的一系列章节。下一章是ASP的快速指南以及ASP.NET Core 1.0新的运行时环境，如果你选择针对微软，你可能会面临的突破性变化以及网络核心框架。接下来的章节将回到“经典的”ASP.asp.net MVC编程主题，更新到ASP.NET MVC 6和保持同样有效，无论你停留在当前的ASP.net平台及相关运行时或升级到ASP.NET Core 1.0平台和相关运行时。ASP的状态是什么?我相信ASP.NET作为一个平台的特性已经接近完成。如果你查看最新版本的MVC和web Forms的新特性列表(这些也是ASP附带的ASP.NET Core 1.0运行时)，你会看到一些次要的东西，比如标签帮助器和视图组件。这些都是值得拥有的好特性，而且肯定会让利刃的开发变得更简单、更有趣，但考虑到你将承受的回归测试和配置兼容性方面的负担，它们并不是升级的关键特性。当一项技术的特性接近完成时，问题就变成了“下一步是什么?”你可以继续使用这项技术，但当你需要解锁新级别的服务并将其交付给客户时，你应该把目光投向别处。由于停止使用HTML和JavaScript开发而重新使用XAML和c#，业界已经失去了改变网络的大好机会，我真的不知道我们还能在ASP之外找到什么。如果让我猜除了目前的技术水平，下一个阶段是什么，我会寻找云服务和基于语音的服务部署——如果这对你经营的业务或持续改善用户体验有意义的话。如果要我预测技术之外的下一步，我会说它将涉及到更加仔细地考虑业务和流程。我想说的是，它还将包括设计网页、社交和移动集成。解决方案，让用户在使用您的软件和服务时感到宾至如归。技术是手段，并不是目的，而asp.net Core 1.0也不例外。

第五章ASP.NET MVC的核心

MVC ASP.net Web表单和ASP.NET MVC以不同的方式设想HTTP请求，尽管这两个框架共享相同的运行时环境，直到ASP.1.0网络核心。在ASP.NET表单中，每个请求都指向显示给定的ASPX页面。作为一个开发人员，你要围绕一堆页面设计一个网站。每个页面都提供了一组可点击的元素来触发一个动作。每个操作都可以通过名称和参数清楚地识别出来:相反，所有的操作都是页面对自己的回发操作。换句话说，在ASP中，您可以处理用户的单击、修改页面的状态并将其呈现回来。在ASP.NET MVC中，其粒度是不同的，每个请求都会导致一个动作的执行——最终是特定控制器类上的一个方法。执行操作的结果与视图模板一起向下传递到视图子系统。然后使用结果和模板为浏览器构建最终响应。ASP.NET MVC应用程序不请求页面，而只是向服务器发出一个请求来执行一个动作。ASP.NET表单与ASP.NET MVC之间的另一个巨大区别是ASP.NET Web表单和ASP.NET MVC缺少服务器控件——能够从参数值生成标记的黑盒组件。而在ASP.NET MVC中，您使用原始的HTML模板为浏览器生成视图。通过这种方式，您可以完全控制标记，并可以使用您最喜欢的JavaScript框架随意应用样式和注入脚本代码。与Web表单不同，ASP.NET MVC是由不同层的代码连接在一起，但没有相互纠缠，也没有形成一个单一的整体块。由于这个原因，可以很容易地用定制组件替换这些紫菜器，从而增强可维护性和可测试性的解决方案。本章将引导您发现控制器的角色和结构——ASP.NET MVC应用程序的基础——并向您展示请求是如何路由到控制器并呈现回浏览器的,作为ASP.NET MVC应用程序中的核心，控制器的设计是一个微妙的部分。控制器的粒度影响项目的组织、代码的分发和用例的实现。控制器中保持(或不保持)的状态可能会影响操作编码的方式，甚至在某种程度上影响应用程序的可伸缩性和可测试性。最后，仅仅因为ASP.NET MVC作为一个受MVC模式启发的框架，这并不意味着你得到了一个完美的分层系统。你自己有很多工作要做，也有很多深思熟虑。一个ASP.NET MVC应用程序通常由各种控制器类组成。你应该有多少个控制器类，实际数量由您决定，并且仅取决于你希望如何组织应用程序的操作。事实上，没有什么可以阻止你围绕包含任何可能请求的方法的单个控制器类来安排应用程序。通常的做法是为应用程序实现的任何重要功能提供一个控制器类。然而，定义“重要功能”的真正含义是有问题的。我建议，作为一个初步的近似，您考虑为你正在实现的每个用例拥有一个控制器类。例如，在电子商务系统中，你可能希望拥有一个用于所有登录和会员操作的控制器，一个用于处理订单或购物车的控制器，一个用于让客户编辑他们的配置文件的控制器。你还应该有另一个控制器类来处理库存产品。查看控制器粒度的另一种方法是，你应该为应用程序主菜单中的每个条目设置一个类。通常，控制器的粒度是用户界面粒度的函数。计划为你提供的用户界面中可能存在的每个重要请求源设置一个控制器。要记住的重要一点是web和控制器类固有的无状态性。每当路由模块捕获一个新请求并将其映射到一个控制器动作时，所选控制器类的一个新实例就会创建。你可以添加到类的任何状态都被绑定到请求的相同生命期。因此，控制器类必须能够从HTTP请求流和HTTP上下文检索工作所需的任何数据。控制器类依赖于HTTP上下文，因此它可以访问绑定到上下文的任何信息，无论它是随请求而来的新信息还是存储在ASP.NET中的信息基础设施，如会话状态或缓存信息。一般的规则是，让控制器类依赖于状态会降低应用程序的可伸缩性，因为这会使在云环境中启动新服务器更加困难，而且不那么即时，ASP.NET MVC和控制器类就像魔术棒一样，挥动它，你就可以写出更干净、更容易阅读和维护的分层代码。控制器类的无状态特性在这方面帮助很大，但这还不够。在ASP.NET MVC中，控制器与触发请求的用户界面和为浏览器生成视图的引擎隔离开来。控制器位于视图和系统后端之间。尽管这种与视图的隔离是受欢迎的，并且修复了ASP的一个弱点。通过设计，系统会让你和视图有最小程度的分离但其他的一切都取决于你。请记住，没有任何东西，即使在ASP.NET MVC中，防止你直接使用ADO.NET调用直接在控制器类中的语句。控制器类不是系统的后端，也不是业务层。相反，它应该被看作是web表单类背后代码的MVC对等物。因此，它肯定属于表示层，而不是业务层。ASP. net的一个特点是.NET MVC的特点是它不匹配URL到磁盘文件;相反，它解析URL以找出下一个要执行的请求操作。然后将一个动作映射到控制器类的一个方法。然后，每个方法执行都会终止，结果被序列化回请求浏览器。最常见的操作结果类型是HTML视图，但也可以使用其他类型的响应，包括JSON、纯文本、二进制数据和重定向。在本章中，我谈到了组成典型ASP工作流的组件、净MVC请求。首先，URL路由HTTP模块检查传入的请求，并找出将处理该请求的控制器和正在调用的方法。接下来，绑定层进入并将被提交的日期(如查询字符串、表单、文件、头或路由)映射到控制器方法的签名。如果映射成功，控制器方法将运行并产生原始结果。原始结果是您希望返回给用户的任何数据，包括集合、字符串、数字、日期等。最后，视图引擎获取一个视图模板并为浏览器生成HTI。控制器并不仅限于返回HTML。在ASP.NET MVC中，控制器可以轻松地返回序列化为XML、纯文本或JSON的任何类型的数据。本章仅触及ASP的皮毛，但它提供了事情如何进行的概述。在下一章中，我将解释Twitter bootstrap——一个CSS和图形库，你可以使用它来有效地安排HTML。

视图的布局和用户界面。

第六章.组织的ASP.NET MVC项目

越来越多的开发人员利用了ASP的各种风格。使用Microsoft Visual Studio编写、编译和测试一个asp.net Core 1.0,ASP.NET MVC应用程序成为一种可能的选择。当您创建一个新的ASP.NET MVC项目，最终运行一个向导，根据模板创建新的文件夹树。一个ASP.NET MVC应用程序需要一些特定的文件夹和文件，不能工作，或者如果这些文件夹不见了，则工作不同。所需文件夹的一个很好的例子是视图文件夹，该文件夹包含HTML视图，必须在生产中复制，包含特定数量的子文件夹，并被恰当地命名

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[603795]，资料为PDF文档或Word文档，PDF文档可免费转换为Word