zoukankan      html  css  js  c++  java
  • 初探Java设计模式2:结构型模式(代理模式,适配器模式等)

    行为型模式

    行为型模式关注的是各个类之间的相互作用,将职责划分清楚,使得我们的代码更加地清晰。

    策略模式

    策略模式太常用了,所以把它放到最前面进行介绍。它比较简单,我就不废话,直接用代码说事吧。

    下面设计的场景是,我们需要画一个图形,可选的策略就是用红色笔来画,还是绿色笔来画,或者蓝色笔来画。

    首先,先定义一个策略接口:

    public interface Strategy {
       public void draw(int radius, int x, int y);
    }
    

    然后我们定义具体的几个策略:

    public class RedPen implements Strategy {
       @Override
       public void draw(int radius, int x, int y) {
          System.out.println("用红色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
       }
    }
    public class GreenPen implements Strategy {
       @Override
       public void draw(int radius, int x, int y) {
          System.out.println("用绿色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
       }
    }
    public class BluePen implements Strategy {
       @Override
       public void draw(int radius, int x, int y) {
          System.out.println("用蓝色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
       }
    }
    

    使用策略的类:

    public class Context {
       private Strategy strategy;
    
       public Context(Strategy strategy){
          this.strategy = strategy;
       }
    
       public int executeDraw(int radius, int x, int y){
          return strategy.draw(radius, x, y);
       }
    }
    

    客户端演示:

    public static void main(String[] args) {
        Context context = new Context(new BluePen()); // 使用绿色笔来画
          context.executeDraw(10, 0, 0);
    }
    

    放到一张图上,让大家看得清晰些:

    strategy-1

    这个时候,大家有没有联想到结构型模式中的桥梁模式,它们其实非常相似,我把桥梁模式的图拿过来大家对比下:

    bridge-1

    要我说的话,它们非常相似,桥梁模式在左侧加了一层抽象而已。桥梁模式的耦合更低,结构更复杂一些。

    观察者模式

    观察者模式对于我们来说,真是再简单不过了。无外乎两个操作,观察者订阅自己关心的主题和主题有数据变化后通知观察者们。

    首先,需要定义主题,每个主题需要持有观察者列表的引用,用于在数据变更的时候通知各个观察者:

    public class Subject {
    
       private List<Observer> observers = new ArrayList<Observer>();
       private int state;
    
       public int getState() {
          return state;
       }
    
       public void setState(int state) {
          this.state = state;
          // 数据已变更,通知观察者们
          notifyAllObservers();
       }
    
       public void attach(Observer observer){
          observers.add(observer);        
       }
    
       // 通知观察者们
       public void notifyAllObservers(){
          for (Observer observer : observers) {
             observer.update();
          }
       }     
    }
    

    定义观察者接口:

    public abstract class Observer {
       protected Subject subject;
       public abstract void update();
    }
    

    其实如果只有一个观察者类的话,接口都不用定义了,不过,通常场景下,既然用到了观察者模式,我们就是希望一个事件出来了,会有多个不同的类需要处理相应的信息。比如,订单修改成功事件,我们希望发短信的类得到通知、发邮件的类得到通知、处理物流信息的类得到通知等。

    我们来定义具体的几个观察者类:

    public class BinaryObserver extends Observer {
    
          // 在构造方法中进行订阅主题
        public BinaryObserver(Subject subject) {
            this.subject = subject;
            // 通常在构造方法中将 this 发布出去的操作一定要小心
            this.subject.attach(this);
        }
    
          // 该方法由主题类在数据变更的时候进行调用
        @Override
        public void update() {
            String result = Integer.toBinaryString(subject.getState());
            System.out.println("订阅的数据发生变化,新的数据处理为二进制值为:" + result);
        }
    }
    
    public class HexaObserver extends Observer {
    
        public HexaObserver(Subject subject) {
            this.subject = subject;
            this.subject.attach(this);
        }
    
        @Override
        public void update() {
              String result = Integer.toHexString(subject.getState()).toUpperCase();
            System.out.println("订阅的数据发生变化,新的数据处理为十六进制值为:" + result);
        }
    }
    

    客户端使用也非常简单:

    public static void main(String[] args) {
        // 先定义一个主题
          Subject subject1 = new Subject();
          // 定义观察者
          new BinaryObserver(subject1);
          new HexaObserver(subject1);
    
          // 模拟数据变更,这个时候,观察者们的 update 方法将会被调用
          subject.setState(11);
    }
    

    output:

    订阅的数据发生变化,新的数据处理为二进制值为:1011
    订阅的数据发生变化,新的数据处理为十六进制值为:B
    

    当然,jdk 也提供了相似的支持,具体的大家可以参考 java.util.Observable 和 java.util.Observer 这两个类。

    实际生产过程中,观察者模式往往用消息中间件来实现,如果要实现单机观察者模式,笔者建议读者使用 Guava 中的 EventBus,它有同步实现也有异步实现,本文主要介绍设计模式,就不展开说了。

    责任链模式

    责任链通常需要先建立一个单向链表,然后调用方只需要调用头部节点就可以了,后面会自动流转下去。比如流程审批就是一个很好的例子,只要终端用户提交申请,根据申请的内容信息,自动建立一条责任链,然后就可以开始流转了。

    有这么一个场景,用户参加一个活动可以领取奖品,但是活动需要进行很多的规则校验然后才能放行,比如首先需要校验用户是否是新用户、今日参与人数是否有限额、全场参与人数是否有限额等等。设定的规则都通过后,才能让用户领走奖品。

    如果产品给你这个需求的话,我想大部分人一开始肯定想的就是,用一个 List 来存放所有的规则,然后 foreach 执行一下每个规则就好了。不过,读者也先别急,看看责任链模式和我们说的这个有什么不一样?

    首先,我们要定义流程上节点的基类:

    public abstract class RuleHandler {
    
          // 后继节点
        protected RuleHandler successor;
    
        public abstract void apply(Context context);
    
        public void setSuccessor(RuleHandler successor) {
            this.successor = successor;
        }
        public RuleHandler getSuccessor() {
            return successor;
        }
    }
    

    接下来,我们需要定义具体的每个节点了。

    校验用户是否是新用户:

    public class NewUserRuleHandler extends RuleHandler {
    
        public void apply(Context context) {
            if (context.isNewUser()) {
                  // 如果有后继节点的话,传递下去
                if (this.getSuccessor() != null) {
                    this.getSuccessor().apply(context);
                }
            } else {
                throw new RuntimeException("该活动仅限新用户参与");
            }
        }
    
    }
    

    校验用户所在地区是否可以参与:

    public class LocationRuleHandler extends RuleHandler {
        public void apply(Context context) {
            boolean allowed = activityService.isSupportedLocation(context.getLocation);
              if (allowed) {
                if (this.getSuccessor() != null) {
                    this.getSuccessor().apply(context);
                }
            } else  {
                throw new RuntimeException("非常抱歉,您所在的地区无法参与本次活动");
            }
        }
    }
    

    校验奖品是否已领完:

    public class LimitRuleHandler extends RuleHandler {
        public void apply(Context context) {
              int remainedTimes = activityService.queryRemainedTimes(context); // 查询剩余奖品
            if (remainedTimes > 0) {
                if (this.getSuccessor() != null) {
                    this.getSuccessor().apply(userInfo);
                }
            } else {
                throw new RuntimeException("您来得太晚了,奖品被领完了");
            }
        }
    }
    

    客户端:

    public static void main(String[] args) {
        RuleHandler newUserHandler = new NewUserRuleHandler();
          RuleHandler locationHandler = new LocationRuleHandler();
          RuleHandler limitHandler = new LimitRuleHandler();
    
          // 假设本次活动仅校验地区和奖品数量,不校验新老用户
          locationHandler.setSuccessor(limitHandler);
          locationHandler.apply(context);
    }
    

    代码其实很简单,就是先定义好一个链表,然后在通过任意一节点后,如果此节点有后继节点,那么传递下去。

    至于它和我们前面说的用一个 List 存放需要执行的规则的做法有什么异同,留给读者自己琢磨吧。

    模板方法模式

    在含有继承结构的代码中,模板方法模式是非常常用的,这也是在开源代码中大量被使用的。

    通常会有一个抽象类:

    public abstract class AbstractTemplate {
        // 这就是模板方法
          public void templateMethod(){
            init();
            apply(); // 这个是重点
            end(); // 可以作为钩子方法
        }
        protected void init() {
            System.out.println("init 抽象层已经实现,子类也可以选择覆写");
        }
          // 留给子类实现
        protected abstract void apply();
        protected void end() {
        }
    }
    

    模板方法中调用了 3 个方法,其中 apply() 是抽象方法,子类必须实现它,其实模板方法中有几个抽象方法完全是自由的,我们也可以将三个方法都设置为抽象方法,让子类来实现。也就是说,模板方法只负责定义第一步应该要做什么,第二步应该做什么,第三步应该做什么,至于怎么做,由子类来实现。

    我们写一个实现类:

    public class ConcreteTemplate extends AbstractTemplate {
        public void apply() {
            System.out.println("子类实现抽象方法 apply");
        }
          public void end() {
            System.out.println("我们可以把 method3 当做钩子方法来使用,需要的时候覆写就可以了");
        }
    }
    

    客户端调用演示:

    public static void main(String[] args) {
        AbstractTemplate t = new ConcreteTemplate();
          // 调用模板方法
          t.templateMethod();
    }
    

    代码其实很简单,基本上看到就懂了,关键是要学会用到自己的代码中。

    状态模式

    update: 2017-10-19

    废话我就不说了,我们说一个简单的例子。商品库存中心有个最基本的需求是减库存和补库存,我们看看怎么用状态模式来写。

    核心在于,我们的关注点不再是 Context 是该进行哪种操作,而是关注在这个 Context 会有哪些操作。

    定义状态接口:

    public interface State {
       public void doAction(Context context);
    }
    

    定义减库存的状态:

    public class DeductState implements State {
    
       public void doAction(Context context) {
          System.out.println("商品卖出,准备减库存");
          context.setState(this);
    
          //... 执行减库存的具体操作
       }
    
       public String toString(){
          return "Deduct State";
       }
    }
    

    定义补库存状态:

    public class RevertState implements State {
        public void doAction(Context context) {
            System.out.println("给此商品补库存");
              context.setState(this);
    
              //... 执行加库存的具体操作
        }
          public String toString() {
            return "Revert State";
        }
    }
    

    前面用到了 context.setState(this),我们来看看怎么定义 Context 类:

    public class Context {
        private State state;
          private String name;
          public Context(String name) {
            this.name = name;
        }
    
          public void setState(State state) {
            this.state = state;
        }
          public void getState() {
            return this.state;
        }
    }
    

    我们来看下客户端调用,大家就一清二楚了:

    public static void main(String[] args) {
        // 我们需要操作的是 iPhone X
        Context context = new Context("iPhone X");
    
        // 看看怎么进行补库存操作
          State revertState = new RevertState();
          revertState.doAction(context);

    行为型模式

    行为型模式关注的是各个类之间的相互作用,将职责划分清楚,使得我们的代码更加地清晰。

    策略模式

    策略模式太常用了,所以把它放到最前面进行介绍。它比较简单,我就不废话,直接用代码说事吧。

    下面设计的场景是,我们需要画一个图形,可选的策略就是用红色笔来画,还是绿色笔来画,或者蓝色笔来画。

    首先,先定义一个策略接口:

    public interface Strategy {
       public void draw(int radius, int x, int y);
    }
    

    然后我们定义具体的几个策略:

    public class RedPen implements Strategy {
       @Override
       public void draw(int radius, int x, int y) {
          System.out.println("用红色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
       }
    }
    public class GreenPen implements Strategy {
       @Override
       public void draw(int radius, int x, int y) {
          System.out.println("用绿色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
       }
    }
    public class BluePen implements Strategy {
       @Override
       public void draw(int radius, int x, int y) {
          System.out.println("用蓝色笔画图,radius:" + radius + ", x:" + x + ", y:" + y);
       }
    }
    

    使用策略的类:

    public class Context {
       private Strategy strategy;
    
       public Context(Strategy strategy){
          this.strategy = strategy;
       }
    
       public int executeDraw(int radius, int x, int y){
          return strategy.draw(radius, x, y);
       }
    }
    

    客户端演示:

    public static void main(String[] args) {
        Context context = new Context(new BluePen()); // 使用绿色笔来画
          context.executeDraw(10, 0, 0);
    }
    

    放到一张图上,让大家看得清晰些:

    strategy-1

    这个时候,大家有没有联想到结构型模式中的桥梁模式,它们其实非常相似,我把桥梁模式的图拿过来大家对比下:

    bridge-1

    要我说的话,它们非常相似,桥梁模式在左侧加了一层抽象而已。桥梁模式的耦合更低,结构更复杂一些。

    观察者模式

    观察者模式对于我们来说,真是再简单不过了。无外乎两个操作,观察者订阅自己关心的主题和主题有数据变化后通知观察者们。

    首先,需要定义主题,每个主题需要持有观察者列表的引用,用于在数据变更的时候通知各个观察者:

    public class Subject {
    
       private List<Observer> observers = new ArrayList<Observer>();
       private int state;
    
       public int getState() {
          return state;
       }
    
       public void setState(int state) {
          this.state = state;
          // 数据已变更,通知观察者们
          notifyAllObservers();
       }
    
       public void attach(Observer observer){
          observers.add(observer);        
       }
    
       // 通知观察者们
       public void notifyAllObservers(){
          for (Observer observer : observers) {
             observer.update();
          }
       }     
    }
    

    定义观察者接口:

    public abstract class Observer {
       protected Subject subject;
       public abstract void update();
    }
    

    其实如果只有一个观察者类的话,接口都不用定义了,不过,通常场景下,既然用到了观察者模式,我们就是希望一个事件出来了,会有多个不同的类需要处理相应的信息。比如,订单修改成功事件,我们希望发短信的类得到通知、发邮件的类得到通知、处理物流信息的类得到通知等。

    我们来定义具体的几个观察者类:

    public class BinaryObserver extends Observer {
    
          // 在构造方法中进行订阅主题
        public BinaryObserver(Subject subject) {
            this.subject = subject;
            // 通常在构造方法中将 this 发布出去的操作一定要小心
            this.subject.attach(this);
        }
    
          // 该方法由主题类在数据变更的时候进行调用
        @Override
        public void update() {
            String result = Integer.toBinaryString(subject.getState());
            System.out.println("订阅的数据发生变化,新的数据处理为二进制值为:" + result);
        }
    }
    
    public class HexaObserver extends Observer {
    
        public HexaObserver(Subject subject) {
            this.subject = subject;
            this.subject.attach(this);
        }
    
        @Override
        public void update() {
              String result = Integer.toHexString(subject.getState()).toUpperCase();
            System.out.println("订阅的数据发生变化,新的数据处理为十六进制值为:" + result);
        }
    }
    

    客户端使用也非常简单:

    public static void main(String[] args) {
        // 先定义一个主题
          Subject subject1 = new Subject();
          // 定义观察者
          new BinaryObserver(subject1);
          new HexaObserver(subject1);
    
          // 模拟数据变更,这个时候,观察者们的 update 方法将会被调用
          subject.setState(11);
    }
    

    output:

    订阅的数据发生变化,新的数据处理为二进制值为:1011
    订阅的数据发生变化,新的数据处理为十六进制值为:B
    

    当然,jdk 也提供了相似的支持,具体的大家可以参考 java.util.Observable 和 java.util.Observer 这两个类。

    实际生产过程中,观察者模式往往用消息中间件来实现,如果要实现单机观察者模式,笔者建议读者使用 Guava 中的 EventBus,它有同步实现也有异步实现,本文主要介绍设计模式,就不展开说了。

    责任链模式

    责任链通常需要先建立一个单向链表,然后调用方只需要调用头部节点就可以了,后面会自动流转下去。比如流程审批就是一个很好的例子,只要终端用户提交申请,根据申请的内容信息,自动建立一条责任链,然后就可以开始流转了。

    有这么一个场景,用户参加一个活动可以领取奖品,但是活动需要进行很多的规则校验然后才能放行,比如首先需要校验用户是否是新用户、今日参与人数是否有限额、全场参与人数是否有限额等等。设定的规则都通过后,才能让用户领走奖品。

    如果产品给你这个需求的话,我想大部分人一开始肯定想的就是,用一个 List 来存放所有的规则,然后 foreach 执行一下每个规则就好了。不过,读者也先别急,看看责任链模式和我们说的这个有什么不一样?

    首先,我们要定义流程上节点的基类:

    public abstract class RuleHandler {
    
          // 后继节点
        protected RuleHandler successor;
    
        public abstract void apply(Context context);
    
        public void setSuccessor(RuleHandler successor) {
            this.successor = successor;
        }
        public RuleHandler getSuccessor() {
            return successor;
        }
    }
    

    接下来,我们需要定义具体的每个节点了。

    校验用户是否是新用户:

    public class NewUserRuleHandler extends RuleHandler {
    
        public void apply(Context context) {
            if (context.isNewUser()) {
                  // 如果有后继节点的话,传递下去
                if (this.getSuccessor() != null) {
                    this.getSuccessor().apply(context);
                }
            } else {
                throw new RuntimeException("该活动仅限新用户参与");
            }
        }
    
    }
    

    校验用户所在地区是否可以参与:

    public class LocationRuleHandler extends RuleHandler {
        public void apply(Context context) {
            boolean allowed = activityService.isSupportedLocation(context.getLocation);
              if (allowed) {
                if (this.getSuccessor() != null) {
                    this.getSuccessor().apply(context);
                }
            } else  {
                throw new RuntimeException("非常抱歉,您所在的地区无法参与本次活动");
            }
        }
    }
    

    校验奖品是否已领完:

    public class LimitRuleHandler extends RuleHandler {
        public void apply(Context context) {
              int remainedTimes = activityService.queryRemainedTimes(context); // 查询剩余奖品
            if (remainedTimes > 0) {
                if (this.getSuccessor() != null) {
                    this.getSuccessor().apply(userInfo);
                }
            } else {
                throw new RuntimeException("您来得太晚了,奖品被领完了");
            }
        }
    }
    

    客户端:

    public static void main(String[] args) {
        RuleHandler newUserHandler = new NewUserRuleHandler();
          RuleHandler locationHandler = new LocationRuleHandler();
          RuleHandler limitHandler = new LimitRuleHandler();
    
          // 假设本次活动仅校验地区和奖品数量,不校验新老用户
          locationHandler.setSuccessor(limitHandler);
          locationHandler.apply(context);
    }
    

    代码其实很简单,就是先定义好一个链表,然后在通过任意一节点后,如果此节点有后继节点,那么传递下去。

    至于它和我们前面说的用一个 List 存放需要执行的规则的做法有什么异同,留给读者自己琢磨吧。

    模板方法模式

    在含有继承结构的代码中,模板方法模式是非常常用的,这也是在开源代码中大量被使用的。

    通常会有一个抽象类:

    public abstract class AbstractTemplate {
        // 这就是模板方法
          public void templateMethod(){
            init();
            apply(); // 这个是重点
            end(); // 可以作为钩子方法
        }
        protected void init() {
            System.out.println("init 抽象层已经实现,子类也可以选择覆写");
        }
          // 留给子类实现
        protected abstract void apply();
        protected void end() {
        }
    }
    

    模板方法中调用了 3 个方法,其中 apply() 是抽象方法,子类必须实现它,其实模板方法中有几个抽象方法完全是自由的,我们也可以将三个方法都设置为抽象方法,让子类来实现。也就是说,模板方法只负责定义第一步应该要做什么,第二步应该做什么,第三步应该做什么,至于怎么做,由子类来实现。

    我们写一个实现类:

    public class ConcreteTemplate extends AbstractTemplate {
        public void apply() {
            System.out.println("子类实现抽象方法 apply");
        }
          public void end() {
            System.out.println("我们可以把 method3 当做钩子方法来使用,需要的时候覆写就可以了");
        }
    }
    

    客户端调用演示:

    public static void main(String[] args) {
        AbstractTemplate t = new ConcreteTemplate();
          // 调用模板方法
          t.templateMethod();
    }
    

    代码其实很简单,基本上看到就懂了,关键是要学会用到自己的代码中。

    状态模式

    update: 2017-10-19

    废话我就不说了,我们说一个简单的例子。商品库存中心有个最基本的需求是减库存和补库存,我们看看怎么用状态模式来写。

    核心在于,我们的关注点不再是 Context 是该进行哪种操作,而是关注在这个 Context 会有哪些操作。

    定义状态接口:

    public interface State {
       public void doAction(Context context);
    }
    

    定义减库存的状态:

    public class DeductState implements State {
    
       public void doAction(Context context) {
          System.out.println("商品卖出,准备减库存");
          context.setState(this);
    
          //... 执行减库存的具体操作
       }
    
       public String toString(){
          return "Deduct State";
       }
    }
    

    定义补库存状态:

    public class RevertState implements State {
        public void doAction(Context context) {
            System.out.println("给此商品补库存");
              context.setState(this);
    
              //... 执行加库存的具体操作
        }
          public String toString() {
            return "Revert State";
        }
    }
    

    前面用到了 context.setState(this),我们来看看怎么定义 Context 类:

    public class Context {
        private State state;
          private String name;
          public Context(String name) {
            this.name = name;
        }
    
          public void setState(State state) {
            this.state = state;
        }
          public void getState() {
            return this.state;
        }
    }
    

    我们来看下客户端调用,大家就一清二楚了:

    public static void main(String[] args) {
        // 我们需要操作的是 iPhone X
        Context context = new Context("iPhone X");
    
        // 看看怎么进行补库存操作
          State revertState = new RevertState();
          revertState.doAction(context);
    
        // 同样的,减库存操作也非常简单
          State deductState = new DeductState();
          deductState.doAction(context);
    
          // 如果需要我们可以获取当前的状态
        // context.getState().toString();
    }
    

    读者可能会发现,在上面这个例子中,如果我们不关心当前 context 处于什么状态,那么 Context 就可以不用维护 state 属性了,那样代码会简单很多。

    不过,商品库存这个例子毕竟只是个例,我们还有很多实例是需要知道当前 context 处于什么状态的。

    行为型模式总结

    行为型模式部分介绍了策略模式、观察者模式、责任链模式、模板方法模式和状态模式,其实,经典的行为型模式还包括备忘录模式、命令模式等,但是它们的使用场景比较有限,而且本文篇幅也挺大了,我就不进行介绍了。

    总结

    学习设计模式的目的是为了让我们的代码更加的优雅、易维护、易扩展。这次整理这篇文章,让我重新审视了一下各个设计模式,对我自己而言收获还是挺大的。我想,文章的最大收益者一般都是作者本人,为了写一篇文章,需要巩固自己的知识,需要寻找各种资料,而且,自己写过的才最容易记住,也算是我给读者的建议吧。

    (全文完)

    转自https://javadoop.com/post/design-pattern

    更多内容请关注微信公众号【Java技术江湖】

    这是一位阿里 Java 工程师的技术小站,作者黄小斜,专注 Java 相关技术:SSM、SpringBoot、MySQL、分布式、中间件、集群、Linux、网络、多线程,偶尔讲点Docker、ELK,同时也分享技术干货和学习经验,致力于Java全栈开发!(关注公众号后回复”资料“即可领取 3T 免费技术学习资源以及我我原创的程序员校招指南、Java学习指南等资源)

    
    
        // 同样的,减库存操作也非常简单
          State deductState = new DeductState();
          deductState.doAction(context);
    
          // 如果需要我们可以获取当前的状态
        // context.getState().toString();
    }
    

    读者可能会发现,在上面这个例子中,如果我们不关心当前 context 处于什么状态,那么 Context 就可以不用维护 state 属性了,那样代码会简单很多。

    不过,商品库存这个例子毕竟只是个例,我们还有很多实例是需要知道当前 context 处于什么状态的。

    行为型模式总结

    行为型模式部分介绍了策略模式、观察者模式、责任链模式、模板方法模式和状态模式,其实,经典的行为型模式还包括备忘录模式、命令模式等,但是它们的使用场景比较有限,而且本文篇幅也挺大了,我就不进行介绍了。

    总结

    学习设计模式的目的是为了让我们的代码更加的优雅、易维护、易扩展。这次整理这篇文章,让我重新审视了一下各个设计模式,对我自己而言收获还是挺大的。我想,文章的最大收益者一般都是作者本人,为了写一篇文章,需要巩固自己的知识,需要寻找各种资料,而且,自己写过的才最容易记住,也算是我给读者的建议吧。

    (全文完)

    转自https://javadoop.com/post/design-pattern

  • 相关阅读:
    session中删除数组中的某一个值
    Windows 查看端口占用进程并关闭
    Debian 9 / Debian 10 / Ubuntu 18.04 / Ubuntu 18.10快速开启BBR加速 或 关闭BBR加速
    在ASP.NET Web API 2中使用Owin OAuth 刷新令牌(示例代码)
    在ASP.NET Web API 2中使用Owin基于Token令牌的身份验证
    Web API 2 的操作结果
    WebApi接口安全性 接口权限调用、参数防篡改防止恶意调用
    关于EF中使用Migrations的一些小提示
    Entity Framework 6 多对多增改操作指南
    用MVC5+EF6+WebApi 做一个考试功能(六) 仓储模式 打造EF通用仓储类
  • 原文地址:https://www.cnblogs.com/xll1025/p/10661882.html
Copyright © 2011-2022 走看看