教你在不使用框架的情况下也能写出现代化 PHP 代码

我为你们准备了一个富有挑战性的事情。接下来你们将以 无 框架的方式开启一个项目之旅。

首先声明， 这篇并非又臭又长的反框架裹脚布文章。也不是推销 非原创 思想 。毕竟， 我们还将在接下来的开发之旅中使用其他框架开发者编写的辅助包。我对这个领域的创新也是持无可非议的态度。

这无关他人，而是关乎己身。作为一名开发者，它将有机会让你成长。

也许无框架开发令你受益匪浅的地方就是，可以从底层运作的层面中汲取丰富的知识。抛却依赖神奇的，帮你处理无法调试和无法真正理解的东西的框架，你将清楚的看到这一切是如何发生的。

很有可能下一份工作中，你并不能随心所以地选择框架开拓新项目。现实就是，在很多高价值，关键业务的 PHP 工作中均使用现有应用。 并且该应用程序是否构建在当前令人舒爽的 Laravel 或 Symfony 等流行框架中，亦或是陈旧过时的 CodeIgniter 或者 FuelPHP 中，更有甚者它可能广泛出现在令人沮丧的 “面向包含体系结构” 的传统的 PHP 应用 之中，所以无框架开发会在将来你所面临的任何 PHP 项目中助你一臂之力。

上古时代， 因为 某些系统 不得不解释分发 HTTP 请求，发送 HTTP 响应，管理依赖关系，无框架开发就是痛苦的鏖战。缺乏行业标准必然意味着，框架中的这些组件高度耦合 。如果你从无框架开始，你终将难逃自建框架的命运。

时至今日，幸亏有 PHP-FIG 完成所有的自动加载和交互工作，无框架开发并非让你白手起家。各色供应商都有这么多优秀的可交互的软件包。把他们组合起来容易得超乎你的想象！

PHP 是如何工作的？

在做其他事之前，搞清楚 PHP 如何与外界沟通是非常重要的。

PHP 以请求 / 响应为周期运行服务端应用程序。与你的应用程序的每一次交互——无论是来自浏览器，命令行还是 REST API ——都是作为请求进入应用程序的。 当接收到请求以后：

  1. 程序开始启动；
  2. 开始处理请求；
  3. 产生响应；
  4. 接着，响应返回给产生请求的相应客户端；
  5. 最后程序关闭。

每一个 请求都在重复以上的交互。

前端控制器

用这些知识把自己武装起来以后，就可以先从我们的前端控制器开始编写程序了。前端控制器是一个 PHP 文件，它处理程序的每一个请求。控制器是请求进入程序后遇到的第一个 PHP 文件，并且（本质上）也是响应走出你应用程序所经过的最后一个文件。

我们使用经典的 Hello, world! 作为例子来确保所有东西都正确连接上，这个例子由 PHP 的内置服务器 驱动。在你开始这样做之前，请确保你已经安装了 PHP7.1 或者更高版本。

创建一个含有 public 目录的项目，然后在该目录里面创建一个index.php 文件，文件里面写入如下代码：

<?php
declare(strict_types=1);

echo ‘Hello, world!‘;

注意，这里我们声明了使用严格模式 —— 作为最佳实践，你应该在应用程序的 每个 PHP 文件的开头 都这样做。因为对从你后面来的开发者来说类型提示对 调试和清晰的交流意图很重要 。

使用命令行（比如 macOS 的终端）切换到你的项目目录并启动 PHP 的内置服务器。

php -S localhost:8080 -t public/

现在，在浏览器中打开 http://localhost:8080/ 。是不是成功地看到了 "Hello, world!" 输出？

很好。接下来我们可以开始进入正题了！

自动加载与第三方包

当你第一次使用 PHP 时，你可能会在你的程序中使用 includes 或 requires 语句来从其他 PHP 文件导入功能和配置。 通常，我们会避免这么干，因为这会使得其他人更难以遵循你的代码路径和理解依赖在哪里。这让调试成为了一个 真正的 噩梦。

解决办法是使用自动加载（autoloading）。 自动加载的意思是：当你的程序需要使用一个类， PHP 在调用该类的时候知道去哪里找到并加载它。虽然从 PHP 5 开始就可以使用这个特性了， 但是得益于 PSR-0 （ 自动加载标准，后来被 PSR-4 取代），其使用率才开始有真正的提升。

我们可以编写自己的自动加载器来完成任务，但是由于我们将要使用的管理第三方依赖的 Composer 已经包含了一个完美的可用的自动加载器，那我们用它就行了。

确保你已经在你的系统上 安装 了 Composer。然后为此项目初始化 Composer：

composer init

这条命令通过交互式引导你创建 composer.json 配置文件。 一旦文件创建好了，我们就可以在编辑器中打开它然后向里面写入 autoload 字段，使他看起来像这个样子（这确保了自动加载器知道从哪里找到我们项目中的类）：

{
    "name": "kevinsmith/no-framework",
    "description": "An example of a modern PHP application bootstrapped without a framework.",
    "type": "project",
    "require": {},
    "autoload": {
        "psr-4": {
            "ExampleApp\\": "src/"
        }
    }
}

现在为此项目安装 composer，它引入了依赖（如果有的话），并为我们创建好了自动加载器：

composer install

更新 public/index.php 文件来引入自动加载器。在理想情况下，这将是你在程序当中使用的少数『包含』语句之一。

<?php
declare(strict_types=1);

require_once dirname(__DIR__) . ‘/vendor/autoload.php‘;

echo ‘Hello, world!‘;

此时如果你刷新浏览器，你将不会看到任何变化。因为自动加载器没有修改或者输出任何数据，所以我们看到的是同样的内容。让我们把 Hello, world! 这个例子移动到一个已经自动加载的类里面看看它是如何运作的。

在项目根目录创建一个名为 src 的目录，然后在里面添加一个叫 HelloWorld.php 的文件，写入如下代码：

<?php
declare(strict_types=1);

namespace ExampleApp;

class HelloWorld
{
    public function announce(): void
    {
        echo ‘Hello, autoloaded world!‘;
    }
}

现在到 public/index.php 里面用 HelloWorld 类的 announce 方法替换掉 echo 语句。

// ...

require_once dirname(__DIR__) . ‘/vendor/autoload.php‘;

$helloWorld = new \ExampleApp\HelloWorld();
$helloWorld->announce();

刷新浏览器查看新的信息！

什么是依赖注入？

依赖注入是一种编程技术，每个依赖项都供给它需要的对象，而不是在对象外获得所需的信息或功能。

举个例子，假设应用中的类方法需要从数据库中读取。为此，你需要一个数据库连接。常用的技术就是创建一个全局可见的新连接。

class AwesomeClass
{
    public function doSomethingAwesome()
    {
        $dbConnection = return new \PDO(
            "{$_ENV[‘type‘]}:host={$_ENV[‘host‘]};dbname={$_ENV[‘name‘]}",
            $_ENV[‘user‘],
            $_ENV[‘pass‘]
        );

        // Make magic happen with $dbConnection
    }
}

但是这样做显得很乱，它把一个并非属于这里的职责置于此地---创建一个* 数据库连接对象 ， 检查凭证 *， 还有 处理一些连接失败的问题---它会导致应用中出现 大量 重复代码。如果你尝试对这个类进行单元测试，会发现根本不可行。这个类和应用环境以及数据库高度耦合。

相反，为何不一开始就搞清楚你的类需要什么？我们只需要首先将 “PDO” 对象注入该类即可。

class AwesomeClass
{
    private $dbConnection;

    public function __construct(\PDO $dbConnection)
    {
        $this->dbConnection = $dbConnection;
    }

    public function doSomethingAwesome()
    {
        // Make magic happen with $this->dbConnection
    }
}

这样更简洁清晰易懂，且更不易产生 Bug。通过类型提示和依赖注入，该方法可以清楚准确地声明它要做的事情，而无需依赖外部调用去获取。在做单元测试的时候，我们可以很好地模拟数据库连接，并将其传入使用。

依赖注入容器 是一个工具，你可以围绕整个应用程序来处理创建和注入这些依赖关系。容器并不需要能够使用依赖注入技术，但随着应用程序的增长并变得更加复杂，它将大有裨益。

我们将使用 PHP 中最受欢迎的 DI 容器之一：名副其实的 PHP-DI。（值得推荐的是它文档中的 依赖注入另解 可能会对读者有所帮助）

依赖注入容器

现在我们已经安装了 Composer ，那么安装 PHP-DI 就轻而易举了，我们继续回到命令行来搞定它。

composer require php-di/php-di

修改 public/index.php 用来配置和构建容器。

// ...

require_once dirname(__DIR__) . ‘/vendor/autoload.php‘;

$containerBuilder = new \DI\ContainerBuilder();
$containerBuilder->useAutowiring(false);
$containerBuilder->useAnnotations(false);
$containerBuilder->addDefinitions([
    \ExampleApp\HelloWorld::class => \DI\create(\ExampleApp\HelloWorld::class)
]);

$container = $containerBuilder->build();

$helloWorld = $container->get(\ExampleApp\HelloWorld::class);
$helloWorld->announce();

没啥大不了的。它仍是一个单文件的简单示例，你很容易能看清它是怎么运行的。

迄今为止, 我们只是在 配置容器 ，所以我们必须 显式地声明依赖关系 （而不是使用 自动装配 或 注解），并且从容器中检索 HelloWorld 对象。

小贴士：自动装配在你开始构建应用程序的时候是一个很不错的特性，但是它隐藏了依赖关系，难以维护。 很有可能在接下里的岁月里， 另一个开发者在不知情的状况下引入了一个新库，然后就造就了多个库实现一个单接口的局面，这将会破坏自动装配，导致一系列让接手者很容易忽视的的不可见的问题。

尽量 引入命名空间，可以增加代码的可读性。

<?php
declare(strict_types=1);

use DI\ContainerBuilder;
use ExampleApp\HelloWorld;
use function DI\create;

require_once dirname(__DIR__) . ‘/vendor/autoload.php‘;

$containerBuilder = new ContainerBuilder();
$containerBuilder->useAutowiring(false);
$containerBuilder->useAnnotations(false);
$containerBuilder->addDefinitions([
    HelloWorld::class => create(HelloWorld::class)
]);

$container = $containerBuilder->build();

$helloWorld = $container->get(HelloWorld::class);
$helloWorld->announce();

现在看来，我们好像是把以前已经做过的事情再拿出来小题大做。

毋需烦心，当我们添加其他工具来帮助我们引导请求时，容器就有用武之地了。它会在适当的时机下按需加载正确的类。

中间件

如果把你的应用想象成一个洋葱，请求从外部进入，到达洋葱中心，最后变成响应返回出去。那么中间件就是洋葱的每一层。它接收请求并且可以处理请求。要么把请求传递到更里层，要么向更外层返回一个响应（如果中间件正在检查请求不满足的特定条件，比如请求一个不存在的路由，则可能发生这种情况）。

如果请求通过了所有的层，那么程序就会开始处理它并把它转换为响应，中间件接收到响应的顺序与接收到请求的顺序相反，并且也能对响应做修改，然后再把它传递给下一个中间件。

下面是一些中间件用例的闪光点：

  • 在开发环境中调试问题
  • 在生产环境中优雅的处理异常
  • 对传入的请求进行频率限制
  • 对请求传入的不支持资源类型做出响应
  • 处理跨域资源共享（CORS）
  • 将请求路由到正确的处理类

那么中间件是实现这些功能的唯一方式吗？当然不是。但是中间件的实现使得你对请求 / 响应这个生命周期的理解更清晰。这也意味着你调试起来更简单，开发起来更快速。

我们将从上面列出的最后一条用例，也就是路由，当中获益。

路由

路由依靠传入的请求信息来确定应当由哪个类来处理它。(例如 URI /products/purple-dress/medium 应该被 ProductDetails::class类接收处理，同时 purple-dress 和 medium 作为参数传入)

在范例应用中，我们将使用流行的 FastRoute 路由，基于 PSR-15兼容的中间件实现。

中间件调度器

为了让我们的应用可以和 FastRoute 中间件---以及我们安装的其他中间件协同工作---我们需要一个中间件调度器。

PSR-15是为中间件和调度器定义接口的中间件标准（在规范中又称“请求处理器”），它允许各式各样的中间件和调度器互相交互。我们只需选择兼容 PSR-15 的调度器，这样就可以确保它能和任何兼容 PSR-15 的中间件协同工作。

我们先安装一个 Relay 作为调度器。

composer require relay/relay:[email protected]

而且根据 PSR-15 的中间件标准要求实现可传递 兼容 PSR-7 的 HTTP 消息, 我们使用 Zend Diactoros 作为 PSR-7 的实现。

composer require zendframework/zend-diactoros

我们用 Relay 去接收中间件。

// ...

use DI\ContainerBuilder;
use ExampleApp\HelloWorld;
use Relay\Relay;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;

// ...

$container = $containerBuilder->build();

$middlewareQueue = [];

$requestHandler = new Relay($middlewareQueue);
$requestHandler->handle(ServerRequestFactory::fromGlobals());

我们在第 16 行使用 ServerRequestFactory::fromGlobals() 把 创建新请求的必要信息合并起来 然后把它传给 Relay。 这正是 Request 进入我们中间件堆栈的起点。

现在我们继续添加 FastRoute 和请求处理器中间件。 ( FastRoute 确定请求是否合法，究竟能否被应用程序处理，然后请求处理器发送 Request 到路由配置表中已注册过的相应处理程序中)

composer require middlewares/fast-route middlewares/request-handler

然后我们给 Hello, world! 处理类定义一个路由。我们在此使用 /hello 路由来展示基本 URI 之外的路由。

// ...

use DI\ContainerBuilder;
use ExampleApp\HelloWorld;
use FastRoute\RouteCollector;
use Middlewares\FastRoute;
use Middlewares\RequestHandler;
use Relay\Relay;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;
use function FastRoute\simpleDispatcher;

// ...

$container = $containerBuilder->build();

$routes = simpleDispatcher(function (RouteCollector $r) {
    $r->get(‘/hello‘, HelloWorld::class);
});

$middlewareQueue[] = new FastRoute($routes);
$middlewareQueue[] = new RequestHandler();

$requestHandler = new Relay($middlewareQueue);
$requestHandler->handle(ServerRequestFactory::fromGlobals());

为了能运行，你还需要修改 HelloWorld 使其成为一个可调用的类， 也就是说 这里类可以像函数一样被随意调用.

// ...

class HelloWorld
{
    public function __invoke(): void
    {
        echo ‘Hello, autoloaded world!‘;
        exit;
    }
}

(注意在魔术方法 __invoke() 中加入exit;。 我们只需1秒钟就能搞定--只是不想让你遗漏这个事)

现在打开 http://localhost:8080/hello ，开香槟吧！

万能胶水

睿智的读者可能很快看出，虽然我们仍旧囿于配置和构建 DI 容器的藩篱之中，容器现在实际上对我们毫无用处。调度器和中间件在没有它的情况下也一样运作。

那它何时才能发挥威力？

嗯，如果---在实际应用程序中总是如此---HelloWorld类具有依赖关系呢?

我们来讲解一个简单的依赖关系，看看究竟发生了什么。

// ...

class HelloWorld
{
    private $foo;

    public function __construct(string $foo)
    {
        $this->foo = $foo;
    }

    public function __invoke(): void
    {
        echo "Hello, {$this->foo} world!";
        exit;
    }
}

刷新浏览器..

WOW！

看下这个 ArgumentCountError.

发生这种情况是因为 HelloWorld 类在构造的时候需要注入一个字符串才能运行，在此之前它只能等着。 这 正是容器要帮你解决的痛点。
我们在容器中定义该依赖关系，然后将容器传给 RequestHandler 去 解决这个问题.

// ...

use Zend\Diactoros\ServerRequestFactory;
use function DI\create;
use function DI\get;
use function FastRoute\simpleDispatcher;

// ...

$containerBuilder->addDefinitions([
    HelloWorld::class => create(HelloWorld::class)
        ->constructor(get(‘Foo‘)),
    ‘Foo‘ => ‘bar‘
]);

$container = $containerBuilder->build();

// ...

$middlewareQueue[] = new FastRoute($routes);
$middlewareQueue[] = new RequestHandler($container);

$requestHandler = new Relay($middlewareQueue);
$requestHandler->handle(ServerRequestFactory::fromGlobals());

嗟夫！当刷新浏览器的时候， "Hello, bar world!"将映入你的眼帘！

正确地发送响应

是否还记得我之前提到过的位于 HelloWorld 类中的 exit 语句?

当我们构建代码时，它可以让我们简单粗暴的获得响应，但是它绝非输出到浏览器的最佳选择。这种粗暴的做法给 HelloWorld 附加了额外的响应工作---其实应该由其他类负责的---它会过于复杂的发送正确的头部信息和 状态码，然后立刻退出了应用，使得 HelloWorld 之后 的中间件也无机会运行了。

记住，每个中间件都有机会在 Request 进入我们应用时修改它，然后 (以相反的顺序) 在响应输出时修改响应。 除了 Request 的通用接口， PSR-7 同样也定义了另外一种 HTTP 消息结构，以辅助我们在应用运行周期的后半部分之用：Response。（如果你想真正了解这些细节，请阅读HTTP 消息以及什么让 PSR-7 请求和响应标准如此之好。）

修改 HelloWorld 返回一个 Response。

// ...

namespace ExampleApp;

use Psr\Http\Message\ResponseInterface;

class HelloWorld
{
    private $foo;

    private $response;

    public function __construct(
        string $foo,
        ResponseInterface $response
    ) {
        $this->foo = $foo;
        $this->response = $response;
    }

    public function __invoke(): ResponseInterface
    {
        $response = $this->response->withHeader(‘Content-Type‘, ‘text/html‘);
        $response->getBody()
            ->write("<html><head></head><body>Hello, {$this->foo} world!</body></html>");

        return $response;
    }
}

然后修改容器给 HelloWorld 提供一个新的 Response 对象。

// ...

use Middlewares\RequestHandler;
use Relay\Relay;
use Zend\Diactoros\Response;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;

// ...

$containerBuilder->addDefinitions([
    HelloWorld::class => create(HelloWorld::class)
        ->constructor(get(‘Foo‘), get(‘Response‘)),
    ‘Foo‘ => ‘bar‘,
    ‘Response‘ => function() {
        return new Response();
    },
]);

$container = $containerBuilder->build();

// ...

如果你现在刷新页面，会发现一片空白。我们的应用正在从中间件调度器返回正确的 Response 对象，但是... 肿么回事？

它啥都没干，就这样。

我们还需要一件东西来包装下：发射器。发射器位于应用程序和 Web 服务器（Apache，nginx等）之间，将响应发送给发起请求的客户端。它实际上拿到了 Response 对象并将其转化为 服务端 API 可理解的信息。

好消息！ 我们已经用来封装请求的 Zend Diactoros 包同样也内置了发送 PSR-7 响应的发射器。

值得注意的是，为了举例，我们只是对发射器的使用小试牛刀。虽然它们可能会更复杂点，真正的应用应该配置成自动化的流式发射器用来应对大量下载的情况， Zend 博客展示了如何实现它。

修改 public/index.php ，用来从调度器那里接收 Response ，然后传给发射器。

// ...

use Relay\Relay;
use Zend\Diactoros\Response;
use Zend\Diactoros\Response\SapiEmitter;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;

// ...

$requestHandler = new Relay($middlewareQueue);
$response = $requestHandler->handle(ServerRequestFactory::fromGlobals());

$emitter = new SapiEmitter();
return $emitter->emit($response);

刷新浏览器，业务恢复了！这次我们用了一种更健壮的方式来处理响应。

以上代码的第 15 行是我们应用中请求/响应周期结束的地方，同时也是 web 服务器接管的地方。

总结

现在你已经获得了现代化的 PHP 代码。 仅仅 44 行代码，在几个被广泛使用，经过全面测试和拥有可靠互操作性的组件的帮助下，我们就完成了一个现代化 PHP 程序的引导。它兼容 PSR-4， PSR-7，PSR-11 以及 PSR-15，这意味着你可以使用自己选择的其他任一供应商对这些标准的实现，来构建自己的 HTTP 消息， DI 容器，中间件，还有中间件调度器。

我们深入理解了我们决策背后使用的技术和原理，但我更希望你能明白，在没有框架的情况下，引导一个新的程序是多么简单的一件事。或许更重要的是，我希望在有必要的时候你能更好的把这些技术运用到已有的项目中去。

作者：summerbluet
链接：https://www.jianshu.com/p/4173f1bb993a
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

原文地址：https://www.cnblogs.com/liliuguang/p/10682587.html

时间： 2024-11-09 16:10:52

教你在不使用框架的情况下也能写出现代化 PHP 代码的相关文章

什么情况下可以不写PHP的结束标签“?&gt;”

我们经常看到有些PHP文件中的代码是只有开始标签,而没有结束标签的,那么什么情况下可以不写这个结束标签,而什么情况下必须写?先来看2个例子: 下面的代码正常运行: <?php echo 123456; 下面的代码报错: <?php echo 123456; <p>abc</p> 原因分析: 前者是纯php代码,可以不写结束标签,也不推荐写结束标签:后者除了php代码,还有html代码,必须要写结束标签. 为什么不推荐前者写结束标签? 在不写php结束标签时,默认从开始标

10个编程小技巧，教你写出高质量代码！

你会写代码吗你会写高质量代码吗你知道怎么写高质量代码吗不要一上来就开始写代码想清楚,再动手今天,分享10个写代码的小技巧教你写出高质量代码↓↓↓ 1.重构思维模式 不要一上来就开始写代码,要掌握尽量多的重构方法,重构思维方式,掌握重构并不一定是要对原来代码的重构,而是让自己在操作之前就想好该怎么去进行. 2.搞清需求再动手 看到需求之后,肯定多多少少会有一些问题,或是理解上的错误,或是功能实现上的问题,这时,必须要交流清楚,否则,后续将会有更多问题. 3.文档也要写 可能不少人觉得文档没人看,写

5月27日经历问题（在有框架的情况下从无到有增加一套功能）

首先菜单管理里面新增一个配置,注意链接路径要对. 然后创建对应的jsp.form对应好路径. 新增与删除点击事件 对应的controller 访问其他界面的时候需要加上回调页面,若传递的参数为page不为pd的话就page.setPd(pd). Mapper里面有的时候可能pd为空,所以建议加上这个判断pd不为空的时候再走下面的判断 原文地址:https://www.cnblogs.com/wh1997/p/10932346.html

高效构建Web应用 教你玩转Play框架 http://www.anool.net/?p=577

Play 框架是一个完整的Web应用开发框架,覆盖了Web应用开发的各个方面.Play 框架在设计的时候借鉴了流行的 Ruby on Rails 和 Grails 等框架,又有自己独有的优势.使用 Play 框架可以方便和高效的开发出 Java Web 应用.通过 Play 框架提供的命令行工具,可以快速的创建出一个 Web 应用的基本骨架.它的 Java 代码动态编译机制,使得修改代码之后,不需要重启服务器就可以直接看到修改之后的结果,调试起来非常方便.它使用 JPA 规范来完成领域对象的持久

Django框架，python2和python3共存的情况下，创建Django项目

一.python2和python3共存的情况下,直接使用 django-admin startproject Django-project 这个时候系统默认使用的是python2创建,可能由于python2未安装Django而报错. 在此可以使用绝对路径创建Django项目E:\Python3\Scripts\django-admin startproject guest 二.使用pycharm创建Django项目,填写好对应信息,就OK了 原文地址:https://www.cnblogs.co

小程序初体验：手把手教你写出第一个小程序（一）

本文笔者将根据quick start中的范例代码,带大家简单地剖析一下小程序的运行方式,并介绍小程序开发中一些通用的特性,带着大家一步步写出自己的小程序. 适用对象:前端初学者,对小程序开发感兴趣者 tips:由于笔者也是一位前端菜鸟,所以尽量用简单直白的语言为大家讲解,如有说的不到位的地方,还望多多指教. 吊了我们一年胃口的小程序终于和大家见面了.经过了一天的发酵,小程序已经成为了今天的超级头条(汪汪哭晕在厕所). 经历了一天媒体对小程序的狂轰滥炸,相信大家对于小程序一定充满了好奇.与其跟风转

Reactjs相比较原生方案是绝对的快吗？哪些情况下React有优势

作者:尤雨溪链接:http://www.zhihu.com/question/31809713/answer/53544875来源:知乎著作权归作者所有,转载请联系作者获得授权. 1. 原生 DOM 操作 vs. 通过框架封装操作. 这是一个性能 vs. 可维护性的取舍.框架的意义在于为你掩盖底层的 DOM 操作,让你用更声明式的方式来描述你的目的,从而让你的代码更容易维护.没有任何框架可以比纯手动的优化 DOM 操作更快,因为框架的 DOM 操作层需要应对任何上层 API 可能产生的操作,它的

关于springMVC框架访问web-inf下的jsp文件

问题:springMVC框架访问web-inf下的jsp文件,具体如下: 使用springMVC,一般都会使用springMVC的视图解析器,大概会这样配置 <property name="prefix" value="/WEB-INF/jsp/"></property> <property name="suffix" value=".jsp"></property> 当我的co

有中国驾照的情况下，在美国怎么考驾照？

Yaaa.知乎用户.阿厚 等人赞同 各州有别,我说一下加州的情况好啦.传说中的理论上说呢,国内的驾照在加州可以直接用,但似乎有个半年时限,若不幸被警车逼停要解释半天还要看交警心情也蛮麻烦.且驾照之于美帝,更相当于身份证明,混bar买酒等等日常必不可少,所以各位打算长久待下来的盆友们还是混个美帝驾照的好呢~ 呐,题主已经有了中国驾照.进阶到大加州驾照步骤如下:1. 带上护照和国内驾照,去到离你最近的DMV( Department of Motor Vehicles). 排好长好长的队(没有没有我没