虚拟机 全局代理 主机代理_虚拟代理简介，第1部分

虚拟机 全局代理 主机代理

One of the most appealing facets of Polymorphism is that it is applicable in a wide variety of situations. Moreover, while the ability to switch out concrete implementations is in and of itself a fundamental object-oriented pillar, commonly used for creating loosely-coupled, interchangeable components, its usage falls shy when it comes to pulling on the reins of domain objects.

多态性最吸引人的方面之一是它适用于多种情况。 而且，尽管切换出具体实现的能力本身就是一个基本的面向对象的Struts，通常用于创建松耦合，可互换的组件，但是在牵扯领域对象的束缚时，它的使用却显得有些害羞。

There’s a somewhat fragile rationale that stands behind this observation: in many cases, domain objects are conceptually modelled up front to operate on concrete sets of data and inside the boundaries of strict relationships which most likely won’t change over time, and where most of the varying business logic is placed in hierarchies of standalone strategy classes (here’s where actual Polymorphism takes place). In such cases, certainly there’s not much room or even compelling reasons to justify having different implementations of domain objects at runtime except for mocking/testing.

该观察结果背后存在一个脆弱的理由：在许多情况下，领域对象在概念上是预先建模的，以在具体的数据集上和严格关系的边界内操作，这些关系很可能不会随时间变化，并且在大多数情况下不同的业务逻辑放置在独立策略类的层次结构中(此处是实际的多态发生的地方)。 在这种情况下，除了模拟/测试之外，没有足够的空间甚至是令人信服的理由来证明在运行时具有不同的域对象实现。

Furthermore, very few will disagree that programming to interfaces is a bad thing, but isn’t it overkill to have one per domain object? After all, a user object will always be modelled with a few typical roles in mind, and if its login() method ever needs to be updated, well… it’ll just be refactored accordingly and the client code won’t complain so long as the mutual contract is maintained. At a glance, it seems that having a whole new user implementation not only isn’t very pragmatic, but it’s simply absurd.

此外，很少有人会反对对接口进行编程是一件坏事，但是每个域对象都拥有一个接口不是太过分了吗？ 毕竟，一个用户对象在建模时总是会考虑一些典型的角色，如果需要更新它的login()方法，那么……它将进行相应的重构，并且客户端代码不会抱怨那么久。因为双方之间的合同得以维持。 乍一看，拥有一个全新的用户实现不仅不十分实用，而且简直荒谬。

A common pitfall with this approach is made apparent when it’s necessary to pull in an aggregate (a domain object made up of other objects or collections) from the database. As each reference to the aggregate implies dealing face to face with the real domain objects, the process unavoidably ends up dropping the entire object graph into the client. It’s not exactly a solution to praise with fervency, even if the objects can be cached later on.

当有必要从数据库中引入聚合(由其他对象或集合组成的域对象)时，使用这种方法的常见陷阱就显而易见了。 由于每个对聚合的引用都意味着要与真实域对象面对面地进行处理，因此该过程不可避免地最终将整个对象图放入客户端。 即使对象以后可以被缓存，这也不是一个以夸张的方式赞美的解决方案。

As usual, simple solutions are the most effective ones, and this applies to the above problem. Rather than fetching the real fat aggregate, if a lightweight substitute is used instead which shares the same interface and knows how to get the aggregate in question from storage then lazy-loading the underlying objects becomes a straightforward process. Often referenced by a few other fancy names, the substitute is generically called a virtual proxy, a sort of stand-in that exploits the neatness of Polymorphism and interacts with the actual domain objects.

通常，简单的解决方案是最有效的解决方案，这适用于上述问题。 如果使用轻量级替代品共享相同的接口，并且知道如何从存储中获取有问题的聚合，那么延迟加载而不是获取实际的脂肪聚合，则延迟加载基础对象将成为一个简单的过程。 通常由其他一些奇特的名字引用，它通常被称为虚拟代理 ，它是一种利用多态性的整洁并与实际域对象进行交互的替身。

Proxies aren’t new to PHP. Doctrine and Zend Framework 2.x make use of them, although with different aims. On behalf of a didactic cause, however, it would be pretty instructive to implement some custom proxy classes and use them for lazy-loading a few basic aggregates from the database, this way illustrating how virtual proxies do their stuff under the hood.

代理对于PHP来说并不陌生。 尽管目标不同，但Doctrine和Zend Framework 2.x还是利用了它们。 但是，就说教原因而言，实现一些自定义代理类并将其用于从数据库