契约式编程不是一门崭新的编程方法论。C/C++ 时代早已有之。Microsoft 在 .NET 4.0 中正式引入契约式编程库。博主以为契约式编程是一种相当不错的编程思想,每一个开发人员都应该掌握。它不但可以使开发人员的思维更清晰,而且对于提高程序性能很有帮助。值得一提的是,它对于并行程序设计也有莫大的益处。

我们先看一段很简单的,未使用契约式编程的代码示例。

  1. // .NET 代码示例
  2. public class RationalNumber
  3. {
  4. private int numberator;
  5. private int denominator;
  6.  
  7. public RationalNumber(int numberator, int denominator)
  8. {
  9. this.numberator = numberator;
  10. this.denominator = denominator;
  11. }
  12.  
  13. public int Denominator
  14. {
  15. get
  16. {
  17. return this.denominator;
  18. }
  19. }
  20. }

上述代码表示一个在 32 位有符号整型范围内的有理数。数学上,有理数是一个整数 a 和一个非零整数 b 的比,通常写作 a/b,故又称作分数(题外话:有理数这个翻译真是够奇怪)。由此,我们知道,有理数的分母不能为 0 。所以,上述代码示例的构造函数还需要写些防御性代码。通常 .NET 开发人员会这样写:

  1. // .NET 代码示例
  2. public class RationalNumber
  3. {
  4. private int numberator;
  5. private int denominator;
  6.  
  7. public RationalNumber(int numberator, int denominator)
  8. {
  9. if (denominator == 0)
  10. throw new ArgumentException("The second argument can not be zero.");
  11. this.numberator = numberator;
  12. this.denominator = denominator;
  13. }
  14.  
  15. public int Denominator
  16. {
  17. get
  18. {
  19. return this.denominator;
  20. }
  21. }
  22. }

下面我们来看一下使用契约式编程的 .NET 4.0 代码示例。为了更加方便的说明,博主在整个示例上都加了契约,但此示例并非一定都加这些契约。

  1. // .NET 代码示例
  2. public class RationalNumber
  3. {
  4. private int numberator;
  5. private int denominator;
  6.  
  7. public RationalNumber(int numberator, int denominator)
  8. {
  9. Contract.Requires(denominator != 0, "The second argument can not be zero.");
  10. this.numberator = numberator;
  11. this.denominator = denominator;
  12. }
  13.  
  14. public int Denominator
  15. {
  16. get
  17. {
  18. Contract.Ensures(Contract.Result<int>() != 0);
  19. return this.denominator;
  20. }
  21. }
  22.  
  23. [ContractInvariantMethod]
  24. protected void ObjectInvariant()
  25. {
  26. Contract.Invariant(this.denominator != 0);
  27. }
  28. }

详细的解释稍后再说。按理,既然契约式编程有那么多好处,那在 C/C++ 世界应该很流行才对。为什么很少看到关于契约式编程的讨论呢?看一下 C++ 的契约式编程示例就知道了。下面是 C++ 代码示例:

  1. //typedef long int32_t;
  2. #include <stdint.h>
  3.  
  4. template
  5. inline void CheckInvariant(T& argument)
  6. {
  7. #ifdef CONTRACT_FULL
  8. argument.Invariant();
  9. #endif
  10. }
  11.  
  12. public class RationalNumber
  13. {
  14. private:
  15. int32_t numberator;
  16. int32_t denominator;
  17.  
  18. public:
  19. RationalNumber(int32_t numberator, int32_t denominator)
  20. {
  21. #ifdef CONTRACT_FULL
  22. ASSERT(denominator != 0);
  23. CheckInvaraint(*this);
  24. #endif
  25. this.numberator = numberator;
  26. this.denominator = denominator;
  27. #ifdef CONTRACT_FULL
  28. CheckInvaraint(*this);
  29. #endif
  30. }
  31.  
  32. public:
  33. int32_t GetDenominator()
  34. {
  35. #ifdef CONTRACT_FULL
  36. // C++ Developers like to use struct type.
  37. class Contract
  38. {
  39. int32_t Result;
  40. Contract()
  41. {
  42. }
  43. ~Contract()
  44. {
  45. }
  46. }
  47. #endif
  48. #ifdef CONTRACT_FULL
  49. Contract contract = new Contract();
  50. contract.Result = denominator;
  51. CheckInvairant(*this);
  52. #endif
  53. return this.denominator;
  54. #ifdef CONTRACT_FULL
  55. CheckInvaraint(*this);
  56. #endif
  57. }
  58.  
  59. protected:
  60. #ifdef CONTRACT_FULL
  61. virtual void Invariant()
  62. {
  63. this.denominator != 0;
  64. }
  65. #endif
  66. }

Woo..., 上述代码充斥了大量的宏和条件编译。对于习惯了 C# 优雅语法的 .NET 开发人员来说,它们是如此丑陋。更重要的是,契约式编程在 C++ 世界并未被标准化,因此项目之间的定义和修改各不一样,给代码造成很大混乱。这正是很少在实际中看到契约式编程应用的原因。但是在 .NET 4.0 中,契约式编程变得简单优雅起来。.NET 4.0 提供了契约式编程库。实际上,.NET 4.0 仅仅是针对 C++ 宏和条件编译的再次抽象和封装。它完全基于 CONTRACTS_FULL, CONTRACTS_PRECONDITIONS Symbol 和 System.Diagnostics.Debug.Assert 方法、System.Environment.FastFail 方法的封装。

那么,何谓契约式编程?

何谓契约式编程

契约是减少大型项目成本的突破性技术。它一般由 Precondition(前置条件), Postcondition(后置条件) 和 Invariant(不变量) 等概念组成。.NET 4.0 除上述概念之外,还增加了 Assert(断言),Assume(假设) 概念。这可以由枚举 ContractFailureKind 类型一窥端倪。

契约的思想很简单。它只是一组结果为真的表达式。如若不然,契约就被违反。那按照定义,程序中就存在纰漏。契约构成了程序规格说明的一部分,只不过该说明从文档挪到了代码中。开发人员都知道,文档通常不完整、过时,甚至不存在。将契约挪移到代码中,就使得程序可以被验证。

正如前所述,.NET 4.0 对宏和条件编译进行抽象封装。这些成果大多集中在 System.Diagnostics.Contracts.Contract 静态类中。该类中的大多数成员都是条件编译。这样,我们就不用再使用 #ifdef 和定义 CONTRACTS_FULL 之类的标记。更重要的是,这些行为被标准化,可以在多个项目中统一使用,并根据情况是否生成带有契约的程序集。

1. Assert

Assert(断言)是最基本的契约。.NET 4.0 使用 Contract.Assert() 方法来特指断言。它用来表示程序点必须保持的一个契约。

  1. Contract.Assert(this.privateField > 0);
  2. Contract.Assert(this.x == 3, "Why isn’t the value of x 3?");

断言有两个重载方法,首参数都是一个布尔表达式,第二个方法的第二个参数表示违反契约时的异常信息。

当断言运行时失败,.NET CLR 仅仅调用 Debug.Assert 方法。成功时则什么也不做。

2. Assume

.NET 4.0 使用 Contract.Assume() 方法表示 Assume(假设) 契约。

  1. Contract.Assume(this.privateField > 0);
  2. Contract.Assume(this.x == 3, "Static checker assumed this");

Assume 契约在运行时检测的行为与 Assert(断言) 契约完全一致。但对于静态验证来说,Assume 契约仅仅验证已添加的事实。由于诸多限制,静态验证并不能保证该契约。或许最好先使用 Assert 契约,然后在验证代码时按需修改。

当 Assume 契约运行时失败时, .NET CLR 会调用 Debug.Assert(false)。同样,成功时什么也不做。

3. Preconditions

.NET 4.0 使用 Contract.Requires() 方法表示 Preconditions(前置条件) 契约。它表示方法被调用时方法状态的契约,通常被用来做参数验证。所有 Preconditions 契约相关成员,至少方法本身可以访问。

  1. Contract.Requires(x != null);

Preconditions 契约的运行时行为依赖于几个因素。如果只隐式定义了 CONTRACTS PRECONDITIONS 标记,而没有定义 CONTRACTS_FULL 标记,那么只会进行检测 Preconditions 契约,而不会检测任何 Postconditions 和 Invariants 契约。假如违反了 Preconditions 契约,那么 CLR 会调用 Debug.Assert(false) 和 Environment.FastFail 方法。

假如想保证 Preconditions 契约在任何编译中都发挥作用,可以使用下面这个方法:

  1. Contract.RequiresAlways(x != null);

为了保持向后兼容性,当已存在的代码不允许被修改时,我们需要抛出指定的精确异常。但是在 Preconditions 契约中,有一些格式上的限定。如下代码所示:

  1. if (x == null) throw new ArgumentException("The argument can not be null.");
  2. Contract.EndContractBlock(); // 前面所有的 if 检测语句皆是 Preconditions 契约

这种 Preconditions 契约的格式严格受限:它必须严格按照上述代码示例格式。而且不能有 else 从句。此外,then 从句也只能有单个 throw 语句。最后必须使用 Contract.EndContractBlock() 方法来标记 Preconditions 契约结束。

看到这里,是不是觉得大多数参数验证都可以被 Preconditions 契约替代?没有错,事实的确如此。这样这些防御性代码完全可以在 Release 被去掉,从而不用做那些冗余的代码检测,从而提高程序性能。但在面向验证客户输入此类情境下,防御性代码仍有必要。再就是,Microsoft 为了保持兼容性,并没有用 Preconditions 契约代替异常。

4. Postconditions

Postconditions 契约表示方法终止时的状态。它跟 Preconditions 契约的运行时行为完全一致。但与 Preconditions 契约不同,Postconditions 契约相关的成员有着更少的可见性。客户程序或许不会理解或使用 Postconditions 契约表示的信息,但这并不影响客户程序正确使用 API 。

对于 Preconditions 契约来说,它则对客户程序有副作用:不能保证客户程序不违反 Preconditions 契约。

A. 标准 Postconditions 契约用法

.NET 4.0 使用 Contract.Ensures() 方法表示标准 Postconditions 契约用法。它表示方法正常终止时必须保持的契约。

  1. Contract.Ensures(this.F > 0);
B. 特殊 Postconditions 契约用法

当从方法体内抛出一个特定异常时,通常情况下 .NET CLR 会从方法体内抛出异常的位置直接跳出,从而辗转堆栈进行异常处理。假如我们需要在异常抛出时还要进行 Postconditions 契约验证,我们可以如下使用:

  1. Contract.EnsuresOnThrows<T>(this.F > 0);

其中小括号内的参数表示当异常从方法内抛出时必须保持的契约,而泛型参数表示异常发生时抛出的异常类型。举例来说,当我们把 T 用 Exception 表示时,无论什么类型的异常被抛出,都能保证 Postconditions 契约。哪怕这个异常是堆栈溢出或任何不能控制的异常。强烈推荐当异常是被调用 API 一部分时,使用 Contract.EnsuresOnThrows<T>() 方法。

C. Postconditions 契约内的特殊方法

以下要讲的这几个特殊方法仅限使用在 Postconditions 契约内。

方法返回值 在 Postconditions 契约内,可以通过 Contract.Result<T>() 方法表示,其中 T 表示方法返回类型。当编译器不能推导出 T 类型时,我们必须显式指出。比如,C# 编译器就不能推导出方法参数类型。

  1. Contract.Ensures(0 < Contract.Result<int>());

假如方法返回 void ,则不必在 Postconditions 契约内使用 Contract.Result<T>() 。

前值(旧值)  在 Postconditions 契约内,通过 Contract.OldValue<T>(e) 表示旧有值,其中 T 是 e 的类型。当编译器能够推导 T 类型时,可以忽略。此外 e 和旧有表达式出现上下文有一些限制。旧有表达式只能出现在 Postconditions 契约内。旧有表达式不能包含另一个旧有表达式。一个很重要的原则就是旧有表达式只能引用方法已经存在的那些旧值。比如,只要方法 Preconditions 契约持有,它必定能被计算。下面是这个原则的一些示例:

  • 方法的旧有状态必定存在其值。比如 Preconditions 契约暗含 xs != null ,xs 当然可以被计算。但是,假如 Preconditions 契约为 xs != null || E(E 为任意表达式),那么 xs 就有可能不能被计算。
  1. Contract.OldValue(xs.Length); // 很可能错误
  • 方法返回值不能被旧有表达式引用。
  1. Contract.OldValue(Contract.Result<int>() + x); // 错误
  • out 参数也不能被旧有表达式引用。
  • 如果某些标记的方法依赖方法返回值,那么这些方法也不能被旧有表达式引用。
  1. Contract.ForAll(0, Contract.Result<int>(), i => Contract.OldValue(xs[i]) > 3); // 错误
  • 旧有表达式不能在 Contract.ForAll() 和 Contract.Exists() 方法内引用匿名委托参数,除非旧有表达式被用作索引器或方法调用参数。
  1. Contract.ForAll(0, xs.Length, i => Contract.OldValue(xs[i]) > 3); // OK
  1. Contract.ForAll(0, xs.Length, i => Contract.OldValue(i) > 3); // 错误
  • 如果旧有表达式依赖于匿名委托的参数,那么旧有表达式不能在匿名委托的方法体内。除非匿名委托是 Contract.ForAll() 和 Contract.Exists() 方法的参数。
  1. Foo( ... (T t) => Contract.OldValue(... t ...) ... ); // 错误
D. out 参数

因为契约出现在方法体前面,所以大多数编译器不允许在 Postconditions 契约内引用 out 参数。为了绕开这个问题,.NET 契约库提供了 Contract.ValueAtReturn<T>(out T t) 方法。

  1. public void OutParam(out int x)
  2. {
  3. Contract.Ensures(Contract.ValueAtReturn(out x) == 3);
  4. x = 3;
  5. }

跟 OldValue 一样,当编译器能推导出类型时,泛型参数可以被忽略。该方法只能出现在 Postconditions 契约。方法参数必须是 out 参数,且不允许使用表达式。

需要注意的是,.NET 目前的工具不能检测确保 out 参数是否正确初始化,而不管它是否在 Postconditions 契约内。因此, x = 3 语句假如被赋予其他值时,编译器并不能发现错误。但是,当编译 Release 版本时,编译器将发现该问题。

5. Object Invariants

对象不变量表示无论对象是否对客户程序可见,类的每一个实例都应该保持的契约。它表示对象处于一个“良好”状态。

在 .NET 4.0 中,对象的所有不变量都应当放入一个受保护的返回 void 的实例方法中。同时用[ContractInvariantMethod]特性标记该方法。此外,该方法体内在调用一系列 Contract.Invariant() 方法后不能再有其他代码。通常我们会把该方法命名为 ObjectInvariant 。

  1. [ContractInvariantMethod]
  2. protected void ObjectInvariant()
  3. {
  4. Contract.Invariant(this.y >= 0);
  5. Contract.Invariant(this.x > this.y);
  6. }

同样,Object Invariants 契约的运行时行为和 Preconditions 契约、Postconditions 契约行为一致。CLR 运行时会在每个公共方法末端检测 Object Invariants 契约,但不会检测对象终结器或任何实现 System.IDisposable 接口的方法。

6. Contract 静态类中的其他特殊方法

.NET 4.0 契约库中的 Contract 静态类还提供了几个特殊的方法。它们分别是:

A. ForAll

Contract.ForAll() 方法有两个重载。第一个重载有两个参数:一个集合和一个谓词。谓词表示返回布尔值的一元方法,且该谓词应用于集合中的每一个元素。任何一个元素让谓词返回 false ,ForAll 停止迭代并返回 false 。否则, ForAll 返回 true 。下面是一个数组内所有元素都不能为 null 的契约示例:

  1. public T[] Foo<T>(T[] array)
  2. {
  3. Contract.Requires(Contract.ForAll(array, (T x) => x != null));
  4. }
B. Exists

它和 ForAll 方法差不多。

7. 接口契约

因为 C#/VB 编译器不允许接口内的方法带有实现代码,所以我们如果想在接口中实现契约,需要创建一个帮助类。接口和契约帮助类通过一对特性来链接。如下所示:

  1. [ContractClass(typeof(IFooContract))]
  2. interface IFoo
  3. {
  4. int Count { get; }
  5. void Put(int value);
  6. }
  7.  
  8. [ContractClassFor(typeof(IFoo))]
  9. sealed class IFooContract : IFoo
  10. {
  11. int IFoo.Count
  12. {
  13. get
  14. {
  15. Contract.Ensures(Contract.Result<int>() >= 0);
  16. return default(int); // dummy return
  17. }
  18. }
  19.  
  20. void IFoo.Put(int value)
  21. {
  22. Contract.Requires(value >= 0);
  23. }
  24. }

.NET 需要显式如上述声明从而把接口和接口方法相关联起来。注意,我们不得不产生一个哑元返回值。最简单的方式就是返回 default(T),不要使用 Contract.Result<T> 。

由于 .NET 要求显式实现接口方法,所以在契约内引用相同接口的其他方法就显得很笨拙。由此,.NET 允许在契约方法之前,使用一个局部变量引用接口类型。如下所示:

  1. [ContractClassFor(typeof(IFoo))]
  2. sealed class IFooContract : IFoo
  3. {
  4. int IFoo.Count
  5. {
  6. get
  7. {
  8. Contract.Ensures(Contract.Result<int>() >= 0);
  9. return default(int); // dummy return
  10. }
  11. }
  12.  
  13. void IFoo.Put(int value)
  14. {
  15. IFoo iFoo = this;
  16. Contract.Requires(value >= 0);
  17. Contract.Requires(iFoo.Count < 10); // 否则的话,就需要强制转型 ((IFoo)this).Count
  18. }
  19. }

8. 抽象方法契约

同接口类似,.NET 中抽象类中的抽象方法也不能包含方法体。所以同接口契约一样,需要帮助类来完成契约。代码示例不再给出。

9. 契约方法重载

所有的契约方法都有一个带有 string 类型参数的重载版本。如下所示:

  1. Contract.Requires(obj != null, "if obj is null, then missiles are fired!");

这样当契约被违反时,.NET 可以在运行时提供一个信息提示。目前,该字符串只能是编译时常量。但是,将来 .NET 可能会改变,字符串可以运行时被计算。但是,如果是字符串常量,静态诊断工具可以选择显示它。

10. 契约特性

A. ContractClass 和 ContractClassFor

这两个特性,我们已经在接口契约和抽象方法契约里看到了。ContractClass 特性用于添加到接口或抽象类型上,但是指向的却是实现该类型的帮助类。ContractClassFor 特性用来添加到帮助类上,指向我们需要契约验证的接口或抽象类型。

B. ContractInvariantMethod

这个特性用来标记表示对象不变量的方法。

C. Pure

Pure 特性只声明在那些没有副作用的方法调用者上。.NET 现存的一些委托可以被认为如此,比如 System.Predicate<T> 和 System.Comparison<T>。

D. RuntimeContracts

这是个程序集级别的特性(具体如何,俺也不太清楚)。

E. ContractPublicPropertyName

这个特性用在字段上。它被用在方法契约中,且该方法相对于字段来说,更具可见性。比如私有字段和公共方法。如下所示:

  1. [ContractPublicPropertyName("PublicProperty")]
  2. private int field;
  3. public int PublicProperty { get { ... } }

F. ContractVerification

这个特性用来假设程序集、类型、成员是否可被验证执行。我们可以使用 [ContractVerification(false)] 来显式标记程序集、类型、成员不被验证执行。

.NET 契约库目前的缺陷

接下来,讲一讲 .NET 契约库目前所存在的一些问题。

  • 值类型中的不变量是被忽略的,不发挥作用。
  • 静态检测还不能处理 Contract.ForAll() 和 Contract.Exists() 方法。
  • C# 迭代器中的契约问题。我们知道 Microsoft 在 C# 2.0 中添加了 yield 关键字来帮助我们完成迭代功能。它其实是 C# 编译器做的糖果。现在契约中,出现了问题。编译器产生的代码会把我们写的契约放入到 MoveNext() 方法中。这个时侯,静态检测就不能保证能够正确完成 Preconditions 契约。

Well,.NET 契约式编程到这里就结束了。嗯,就到这里了。

PS : .NET 契约库虽然已经相当优雅。但博主以为,其跟 D 语言实现的契约式编程仍有一段距离。

PS : 有谁愿意当俺的 Mentor 。您能够享受这样的权利和义务:地狱般恐怖的提问和骚扰。非不厌其烦者勿扰。

.NET 4.0 中的契约式编程的更多相关文章

  1. PHP 面向对象编程和设计模式 (1/5) - 抽象类、对象接口、instanceof 和契约式编程

    PHP高级程序设计 学习笔记 2014.06.09 什么是面向对象编程 面向对象编程(Object Oriented Programming,OOP)是一种计算机编程架构.OOP 的一条基本原则是计算 ...

  2. 第三单元总结——JML契约式编程

    OO第三单元博客作业--JML与契约式编程 OO第三单元的三次作业都是在课程组的JML规格下完成.完成作业的过程是契约式编程的过程:设计者完成规格设计,实现者按照规格具体实现.作业正确性的检查同样围绕 ...

  3. Android中使用反应式编程RxJava

    GitHut 地址: https://github.com/ReactiveX/RxAndroid (1)RxJava简介: RxJava 是一个在Java虚拟机上实现的响应式扩展库:提供了基于obs ...

  4. Net中的反应式编程

    Net中的反应式编程(Reactive Programming)   系列主题:基于消息的软件架构模型演变 一.反应式编程(Reactive Programming) 1.什么是反应式编程:反应式编程 ...

  5. (转)Spring Boot 2 (十):Spring Boot 中的响应式编程和 WebFlux 入门

    http://www.ityouknow.com/springboot/2019/02/12/spring-boot-webflux.html Spring 5.0 中发布了重量级组件 Webflux ...

  6. Spring Boot 2 (十):Spring Boot 中的响应式编程和 WebFlux 入门

    Spring 5.0 中发布了重量级组件 Webflux,拉起了响应式编程的规模使用序幕. WebFlux 使用的场景是异步非阻塞的,使用 Webflux 作为系统解决方案,在大多数场景下可以提高系统 ...

  7. Java 中的链式编程

    前言 ​ 在写项目的时候,有一个实体类有好多个属性,new 出来之后需要不停的使用setXXX( )方法,效率低而且代码可读性差,查询了下发现可以实现实体类的链式编程. public class Us ...

  8. .Net中的反应式编程(Reactive Programming)

    系列主题:基于消息的软件架构模型演变 一.反应式编程(Reactive Programming) 1.什么是反应式编程:反应式编程(Reactive programming)简称Rx,他是一个使用LI ...

  9. 由表单验证说起,关于在C#中尝试链式编程的实践

    在web开发中必不可少的会遇到表单验证的问题,为避免数据在写入到数据库时出现异常,一般比较安全的做法是前端会先做一次验证,通过后把数据提交到后端再验证一次,因为仅仅靠前端验证是不安全的,有太多的htt ...

随机推荐

  1. Bootloader和Root

    1. Unlock Bootloader是解除系统启动加载器(Bootloader)的原厂限制, 让用户可以使用到更多的功能(如刷新内核.刷ROM.修改超频....) Bootloader(系统启动加 ...

  2. JAVA多线程之synchronized和volatile实例讲解

    在多线程中,提到线程安全.线程同步,我们经常会想到两个关键字:volatile和synchronized,那么这两者有什么区别呢? 1. volatile修饰的变量具有可见性 volatile是变量修 ...

  3. 【C/C++语言】int 在计算机内部的存储

    int在32位计算机中占4个字节,主要是想弄清楚这4个字节的在内存中存放的顺序. #include <iostream> using namespace std; typedef stru ...

  4. 图解Sysprep封装系统

    图解Sysprep封装系统     一.使用安装管理器工具创建 Sysprep.inf 应答文件 要安装“安装管理器”工具并创建应答文件,请按照下列步骤操作: 1)打开“我的电脑”,然后打开 Wind ...

  5. python文件目录操作大全

    python只获取当前目录下的文件夹及文件名 list = os.listdir(rootdir)#列出目录下的所有文件和目录 for line in list: filepath = os.path ...

  6. buildroot 修改root密码后无法登录ssh解决方法

    客户说想修改root密码后再登录ssh, 研究了一下,是因为ssh登录是匹配了之前的 密码生成文件,只要把之前的密码生成文件删除就可以. 过程如下: 删除 /etc/ssh/ssh_host*. rm ...

  7. imx lcd HV和DE模式转换

    有些时候拿到的lcd手册中关于芯片的时序使用的DE模式的,而imx6内核中使用的参数设置趋势HV模式,应此就需要将DE模式的参数转化为HV模式. 参考链接: https://community.nxp ...

  8. Spring Boot可以离开Spring Cloud独立使用开发项目,但是Spring Cloud离不开Spring Boot,属于依赖的关系。

    Spring Boot 是 Spring 的一套快速配置脚手架,可以基于Spring Boot 快速开发单个微服务,Spring Cloud是一个基于Spring Boot实现的云应用开发工具:Spr ...

  9. java---servlet与filter的联系与区别

    filter是一个可以复用的代码片段,可以用来转换HTTP请求.响应和头信息.Filter不像Servlet,它不能产生一个请求或者响应,它只是修改对某一资源的请求,或者修改从某一的响应. 最近使用插 ...

  10. java----EL表达式

     Java Web中的EL(表达式语言)详解 表达式语言(Expression Language)简称EL,它是JSP2.0中引入的一个新内容.通过EL可以简化在JSP开发中对对象的引用,从而规范页面 ...