在PHP中是否有单子与数据库访问的用例?[英] Is there a use-case for singletons with database access in PHP?

本文是小编为大家收集整理的关于在PHP中是否有单子与数据库访问的用例?的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

我通过PDO访问我的MySQL数据库.我正在设置对数据库的访问,我的第一次尝试是使用以下内容:

我想到的第一件事是global:

$db = new PDO('mysql:host=127.0.0.1;dbname=toto', 'root', 'pwd');

function some_function() {
    global $db;
    $db->query('...');
}

这被认为是一种不好的做法.稍作搜索后,我最终得到了 singleton pattern ,哪个

"适用于需要一个类实例的情况."

根据手册中的示例,我们应该这样做:

class Database {
    private static $instance, $db;

    private function __construct(){}

    static function singleton() {
        if(!isset(self::$instance))
            self::$instance = new __CLASS__;

        return self:$instance;
    }

    function get() {
        if(!isset(self::$db))
            self::$db = new PDO('mysql:host=127.0.0.1;dbname=toto', 'user', 'pwd')

        return self::$db;
    }
}

function some_function() {
    $db = Database::singleton();
    $db->get()->query('...');
}

some_function();

当我可以这样做时,为什么我需要那个相对较大的班级?

class Database {
    private static $db;

    private function __construct(){}

    static function get() {
        if(!isset(self::$db))
            self::$db = new PDO('mysql:host=127.0.0.1;dbname=toto', 'user', 'pwd');

        return self::$db;
    }
}

function some_function() {
    Database::get()->query('...');
}

some_function();

这最后一个功能完美,我不再担心$db.

我如何创建一个较小的单例类,或者我在PHP中缺少的单例吗?

推荐答案

好吧,当我刚开始职业生涯时,我想知道一段时间.实施了不同的方式,并提出了两个理由选择不使用静态类,但是它们很大.

一个人是,您会发现您绝对确定您永远不会有一个超过一个实例的东西,最终您最终会有第二个实例.您最终可能会出现第二个显示器,第二个数据库,第二个服务器 -

发生这种情况时,如果您使用的是静态类,则与使用Singleton相比,您的重构要差得多.单身人士本身就是一种静态的模式,但是它可以很容易地将其转换为智能的工厂模式 - 甚至可以将依赖性注入转换为且没有太多麻烦.例如,如果您的单身人士通过getInstance()获得,则可以轻松地将其更改为getInstance(databasename)并允许多个数据库 - 没有其他代码更改.

第二个问题是测试(老实说,这与第一个问题相同).有时您想用模拟数据库替换数据库.实际上,这是数据库对象的第二个实例.静态类要比单身顿(Singleton)更难处理,您只需要嘲笑getInstance()方法,而不是静态类中的每个方法(在某些语言中可能非常困难).

这确实归结于习惯 - 当人们说"全球群体"不好时,他们有很好的理由这样说,但是直到您自己遇到问题之前,这可能并不总是很明显的.

您能做的最好的事情就是问(就像您一样),然后做出选择并观察您的决定的后果.拥有来解释您的代码随着时间的发展的知识比首先要做的知识要重要得多.

其他推荐答案

单例很少 - 如果不说否 - 在php.

在对象生活在共享内存中的语言中,可以使用单例来保持内存使用率低.您没有创建两个对象,而是从全球共享的应用程序内存中引用现有实例.在PHP中,没有这样的应用程序内存.在一个请求中创建的单身人士准确地生存了该请求.同时完成另一个请求中创建的单例仍然是一个完全不同的实例.因此,Singleton的两个主要目的之一不适用.

此外,在您的应用程序中只能在概念上仅存在的许多对象不一定需要语言机制来执行此功能.如果您只需要一个实例,则不要实例化另一个.只有当您可能没有其他实例时,例如当您创建第二个实例时,小猫死了,您可能会有一个有效的单例.

另一个目的是在同一请求中对实例进行全局访问点.虽然这听起来可能是理想的,但确实不是,因为它与全球范围(如任何全球范围和静态)创建了耦合. 这使单位测试变得更加困难一般而言,较低的可维护.有一些方法可以减轻这种情况,但是通常,如果您需要在许多类中具有相同的实例,请使用依赖项注入.

请参阅我的幻灯片 singletons的" rel =" noreferrer" - 为什么它们不好以及如何从应用程序中消除它们以获取其他信息.

均匀 erich gamma ,Singleton Pattern的一个发明家之一,如今已怀疑这种模式:

我赞成掉落Singleton.它的使用是几乎总是设计气味"

进一步阅读

如果在上面之后,您仍然需要帮助决定:

 Singleton决策图

其他推荐答案

谁需要php中的单例?

请注意,几乎所有对单例的异议都来自技术的角度 - 但它们的范围也非常有限.特别是对于PHP.首先,我将列出使用单例的一些原因,然后我将分析对单例使用的异议.首先,需要它们的人:

- 正在编码大型框架/代码库的人(将在许多不同的环境中使用)必须与以前存在的不同框架/代码库一起使用,需要实施许多不同的,更改,甚至甚至客户/老板/管理/单位领导者的异想天开请求.

请参阅,单例模式是自包容的.完成后,单身类类是您包含在其中的任何代码上的刚性,它的作用与您创建其方法和变量的方式完全一样.它在给定请求中始终是相同的对象.由于不能将其创建两次是两个不同的对象,因此您知道代码中任何给定点的单例对象是什么 - 即使将单例插入到两个,三个不同的,旧的,甚至是意大利面条代码库中.因此,它使其在开发目的方面变得更容易 - 即使有很多人在该项目中工作,当您看到单身人士在任何给定的代码库中以某个点的初始化时,您都知道它是什么,它的作用,它的作用,如何确实是,并且它所处的状态.如果是传统类,您将需要跟踪该对象首先创建的位置,在代码的那个点及其特定状态之前,它在其中创建了哪些方法.但是,在那里放下单身人士,如果您放弃了适当的调试和信息方法并在编码时跟踪到单例中,您将确切知道它是什么.因此,这使得必须使用不同代码库的人更容易,并且需要将代码集成到以前的哲学上,或者由您没有联系的人进行的代码. (也就是说,供应商项目 - 没有更多的东西,没有任何支持).

- 需要与第三方合作的人 apis .

如果您仔细观察,这与早期情况并没有太大不同 - 第三方API,服务,网站,就像您无法控制的外部,隔离的代码库一样.一切都会发生.因此,借助Singleton会话/用户类,您可以从第三方提供商中管理任何类型的会话/授权实现,例如 openID facebook twitter 等等 - 您可以同时从同一单身对象进行所有这些操作 - 在任何给定的任何给定状态下,它易于访问指指您将其插入的任何代码.您甚至可以在您自己的网站/应用程序中为同一用户为多个不同的第三方API/服务创建多个会话,并与他们一起做任何您想做的事情.

当然,所有这些都可以通过使用普通类和对象来使用传统方法 - 捕获是,与传统的类别/对象相比,Singleton更加整洁,更整洁,因此更容易管理/可测试这种情况.

- 需要进行快速发展的人

单身人士的全球式行为使得使用具有单身人士集合的框架构建任何类型的代码变得更加容易,因为一旦您很好地构造了单身人士,就可以构建单身人士,建立,成熟和设定的方法将是随时随地在任何时候都可以始终如一地使用.需要一些时间才能使您的课程成熟,但是在那之后,它们稳固,一致且有用.您可以在单身顿中使用尽可能多的方法做您想做的任何事情,尽管这可能会增加对象的内存足迹,但它会带来快速开发所需的时间的节省 - 您在一个给定的实例中未使用的方法可以在另一个集成的应用程序中使用一个应用程序,您只需对客户/Boss/Project Manager进行一些修改就会询问的新功能.

您明白了.现在,让我们继续对单例的异议和 邪恶的十字军东征对有用的东西 :

- 最重要的反对是它使测试更加困难.

实际上,即使可以通过采取适当的预防措施并将调试例程编码为单身人士,它在某种程度上很容易减轻,这是您的意识到,您会意识到您将调试单身人士.但是请看,这与那里存在的任何其他编码理念/方法/模式都没有太大不同 - 仅仅是,单例相对较新且不广泛,因此当前的测试方法最终与它们相当不相容.但这在编程语言的任何方面都没有什么不同 - 不同的样式需要不同的方法.

一点点这个反对意见是平坦的,它忽略了以下事实:开发的应用程序不是用于"测试",而测试并不是唯一进入应用程序开发的阶段/过程.开发了用于生产使用的应用.正如我在"需要单身人士"部分中解释的那样,单身人士可以从必须与许多不同的代码库/应用程序/第三方服务一起使用代码工作的复杂性,从而大大减少了很多.在测试中可能会浪费的时间是开发和部署的时间.这在这个第三方身份验证/应用程序/集成的时代特别有用 - Facebook,Twitter,OpenID,更多以及谁知道下一步.

尽管可以理解 - 程序员在不同的情况下工作,具体取决于他们的职业.对于那些在相对较大的公司工作的人来说,以舒适的方式调整了不同的,定义的软件/应用程序,并且没有预算削减/裁员的厄运,并且随之而来的是需要做很多与许多不同事情的事情Singletons是一种便宜/快速/可靠的时尚,似乎并不是那么必要.甚至可能对他们已经拥有的东西进行滋扰/障碍.

但是,对于那些需要在"敏捷"开发的肮脏战es中工作的人,必须从其客户/经理/项目中实施许多不同的请求(有时是不合理的),因此,由于较早解释的原因,单人是一个节省的恩典.<<<<<<<<<<<<<<<<<<

- 另一个异议是其内存足迹较高

由于每个客户端的每个请求都会存在一个新的单例,所以这可能是PHP的反对意见.使用构造不良和使用的单例,如果应用程序在任何给定点为许多用户提供了许多用户,则应用程序的内存足迹可能会更高.

不过,这对于在编码事物时可以采用的任何方法都是有效的.应该提出的问题是,这些单例持有和处理的方法是不必要的吗?因为,如果应用程序中的许多请求中都需要它们,那么即使您不使用单例,这些方法和数据也会通过代码以某种形式存在于您的应用程序中.因此,当您将传统类对象1/3初始化到代码处理中,并将其3/4销毁时,这一切都将成为您要节省多少内存的问题.

请参阅,当这样说,问题就变得非常无关 - 不应有不必要的方法,无论如何,无论您使用单胎是否使用singterons,都在代码中保存在对象中的数据.因此,对单身人士的这种反对真的很有趣,因为它假设将存在不必要的方法,即从您使用的类创建的对象中的数据.

- 一些无效的反对意见,例如"使多个数据库康复不可能/更难/更难'

我什至无法开始理解这一异议,当所有一个人都需要维护多个数据库连接,多个数据库选择,多个数据库查询时,给定的单例中的多个结果集只是将它们保留在变量/阵列中只要需要它们.尽管您可以发明任何要使用的方法来实现这一目标,但这可能与将它们保持在数组中一样简单.但是,让我们检查给定单元中的最简单情况,使用变量和数组:

想象以下是给定数据库Singleton中的:

$ this - > connections = array (); (错误的语法,我只是这样键入它是为了给您图片 - 变量的正确声明为public $ connections = array();它的用法是$ this-> connections ['ConnectionKey'自然))

您可以设置,并以这种方式在任何给定时间保持多个连接.查询,结果集等也是如此.

$ this - >查询(querystring,'queryName',$ this-> connections ['prementulrConnection']);

只能对所选连接的选定数据库进行查询,然后存储在您的

$ this - >结果

带有键'queryName'的数组.当然,您需要对此进行查询方法 - 这是微不足道的.

这使您能够维护几乎无限的数量(当然允许的资源限制)不同的数据库连接,结果集尽可能多.它们可在任何给定代码库中的任何给定点中可用于该单元类已实例化的任何代码.

.

当然,您自然需要释放结果集,并且在不需要时进行连接 - 但这不用说,这不是针对单例或任何其他编码方法/样式/概念的特定特定的.

在这一点上,您可以看到如何维护同一单人顿中的第三方应用程序或服务的多个连接/状态.没有那么不同.

长话短说,最终,辛格尔顿的模式只是与其他任何方法/样式/哲学一起编程的方法,并且在正确的位置以正确的方式使用时,它们和其他任何方法一样有用.与任何事物没有什么不同.

您会注意到,在大多数遭受单身人士的文章中,您还会看到对"全球"为"邪恶"的引用.

让我们面对现实吧 - 任何未正确使用,滥用,滥用,滥用,都是邪恶的.这不仅限于任何语言,任何编码概念,任何方法.每当您看到某人发行像" X IS Evil"这样的笼统说法时,就会逃离该文章.这是一个有限观点的产物很高的机会 - 即使观点是特定事物经验多年的结果 - 通常最终是在给定的风格/方法中工作太多的结果 - 典型的知识保守主义.

可以为此提供无尽的例子,从"全球是邪恶的"到" iframe是邪恶的".大约在10年前,甚至提议在任何给定应用中使用iframe都是异端的.然后是Facebook,到处都是iframe,看看发生了什么 - iframes不再那么邪恶了.

仍然有些人坚持认为自己是"邪恶的" - 有时也是有充分理由的 - 但是,如您所见,有需要,iframe填补了需求和工作,因此整个世界只是移动.

程序员/编码器/软件工程师的最重要资产是免费,开放和灵活的头脑.

本文地址:https://www.itbaoku.cn/post/627434.html

问题描述

I access my MySQL database via PDO. I'm setting up access to the database, and my first attempt was to use the following:

The first thing I thought of is global:

$db = new PDO('mysql:host=127.0.0.1;dbname=toto', 'root', 'pwd');

function some_function() {
    global $db;
    $db->query('...');
}

This is considered a bad practice. After a little search, I ended up with the Singleton pattern, which

"applies to situations in which there needs to be a single instance of a class."

According to the example in the manual, we should do this:

class Database {
    private static $instance, $db;

    private function __construct(){}

    static function singleton() {
        if(!isset(self::$instance))
            self::$instance = new __CLASS__;

        return self:$instance;
    }

    function get() {
        if(!isset(self::$db))
            self::$db = new PDO('mysql:host=127.0.0.1;dbname=toto', 'user', 'pwd')

        return self::$db;
    }
}

function some_function() {
    $db = Database::singleton();
    $db->get()->query('...');
}

some_function();

Why do I need that relatively large class when I can do this?

class Database {
    private static $db;

    private function __construct(){}

    static function get() {
        if(!isset(self::$db))
            self::$db = new PDO('mysql:host=127.0.0.1;dbname=toto', 'user', 'pwd');

        return self::$db;
    }
}

function some_function() {
    Database::get()->query('...');
}

some_function();

This last one works perfectly and I don't need to worry about $db anymore.

How can I create a smaller singleton class, or is there a use-case for singletons that I'm missing in PHP?

推荐答案

Okay, I wondered over that one for a while when I first started my career. Implemented it different ways and came up with two reasons to choose not to use static classes, but they are pretty big ones.

One is that you will find that very often something that you are absolutely sure that you'll never have more than one instance of, you eventually have a second. You may end up with a second monitor, a second database, a second server--whatever.

When this happens, if you have used a static class you're in for a much worse refactor than if you had used a singleton. A singleton is an iffy pattern in itself, but it converts fairly easily to an intelligent factory pattern--can even be converted to use dependency injection without too much trouble. For instance, if your singleton is gotten through getInstance(), you can pretty easily change that to getInstance(databaseName) and allow for multiple databases--no other code changes.

The second issue is testing (And honestly, this is the same as the first issue). Sometimes you want to replace your database with a mock database. In effect this is a second instance of the database object. This is much harder to do with static classes than it is with a singleton, you only have to mock out the getInstance() method, not every single method in a static class (which in some languages can be very difficult).

It really comes down to habits--and when people say "Globals" are bad, they have very good reasons to say so, but it may not always be obvious until you've hit the problem yourself.

The best thing you can do is ask (like you did) then make a choice and observe the ramifications of your decision. Having the knowledge to interpret your code's evolution over time is much more important than doing it right in the first place.

其他推荐答案

Singletons have very little - if not to say no - use in PHP.

In languages where objects live in shared memory, Singletons can be used to keep memory usage low. Instead of creating two objects, you reference an existing instance from the globally shared application memory. In PHP there is no such application memory. A Singleton created in one Request lives for exactly that request. A Singleton created in another Request done at the same time is still a completely different instance. Thus, one of the two main purposes of a Singleton is not applicable here.

In addition, many of the objects that can conceptually exist only once in your application do not necessarily require a language mechanism to enforce this. If you need only one instance, then don't instantiate another. It's only when you may have no other instance, e.g. when kittens die when you create a second instance, that you might have a valid Use Case for a Singleton.

The other purpose would be to have a global access point to an instance within the same Request. While this might sound desirable, it really isnt, because it creates coupling to the global scope (like any globals and statics). This makes Unit-Testing harder and your application in general less maintainable. There is ways to mitigate this, but in general, if you need to have the same instance in many classes, use Dependency Injection.

See my slides for Singletons in PHP - Why they are bad and how you can eliminate them from your applications for additional information.

Even Erich Gamma, one of the Singleton pattern's inventors, doubts this pattern nowadays:

"I'm in favor of dropping Singleton. Its use is almost always a design smell"

Further reading

If, after the above, you still need help deciding:

Singleton Decision Diagram

其他推荐答案

Who needs singletons in PHP?

Notice that almost all of the objections to singletons come from technical standpoints - but they are also VERY limited in their scope. Especially for PHP. First, I will list some of the reasons for using singletons, and then I will analyze the objections to usage of singletons. First, people who need them:

- People who are coding a large framework/codebase, which will be used in many different environments, will have to work with previously existing, different frameworks/codebases, with the necessity of implementing many different, changing, even whimsical requests from clients/bosses/management/unit leaders do.

See, the singleton pattern is self inclusive. When done, a singleton class is rigid across any code you include it in, and it acts exactly like how you created its methods and variables. And it is always the same object in a given request. Since it cannot be created twice to be two different objects, you know what a singleton object is at any given point in a code - even if the singleton is inserted to two, three different, old, even spaghetti codebases. Therefore, it makes it easier in terms of development purposes - even if there are many people working in that project, when you see a singleton being initialized in one point in any given codebase, you know what it is, what it does, how it does, and the state it is in. If it was the traditional class, you would need to keep track of where was that object first created, what methods were invoked in it until that point in the code, and its particular state. But, drop a singleton there, and if you dropped proper debugging and information methods and tracking into the singleton while coding it, you know exactly what it is. So therefore, it makes it easier for people who have to work with differing codebases, with the necessity of integrating code which was done earlier with different philosophies, or done by people who you have no contact with. (that is, vendor-project-company-whatever is there no more, no support nothing).

- People who need to work with third-party APIs, services and websites.

If you look closer, this is not too different than the earlier case - third-party APIs, services, websites, are just like external, isolated codebases over which you have NO control. Anything can happen. So, with a singleton session/user class, you can manage ANY kind of session/authorization implementation from third-party providers like OpenID, Facebook, Twitter and many more - and you can do these ALL at the same time from the SAME singleton object - which is easily accessible, in a known state at any given point in whatever code you plug it into. You can even create multiple sessions to multiple different, third-party APIs/services for the SAME user in your own website/application, and do whatever you want to do with them.

Of course, all of this also can be tone with traditional methods by using normal classes and objects - the catch here is, singleton is tidier, neater and therefore because of that manageable/testable easier compared to traditional class/object usage in such situations.

- People who need to do rapid development

The global-like behavior of singletons make it easier to build any kind of code with a framework which has a collection of singletons to build on, because once you construct your singleton classes well, the established, mature and set methods will be easily available and usable anywhere, anytime, in a consistent fashion. It takes some time to mature your classes, but after that, they are rock solid and consistent, and useful. You can have as many methods in a singleton doing whatever you want, and, though this may increase the memory footprint of the object, it brings much more savings in time required for rapid development - a method you are not using in one given instance of an application can be used in another integrated one, and you can just slap a new feature which client/boss/project manager asks just by a few modifications.

You get the idea. Now lets move on to the objections to singletons and the unholy crusade against something that is useful:

- Foremost objection is that it makes testing harder.

And really, it does to some extent, even if it can be easily mitigated by taking proper precautions and coding debugging routines into your singletons WITH the realization that you will be debugging a singleton. But see, this isnt too different than ANY other coding philosophy/method/pattern that is out there - it's just that, singletons are relatively new and not widespread, so the current testing methods are ending up comparably incompatible with them. But that is not different in any aspect of programming languages - different styles require different approaches.

One point this objection falls flat in that, it ignores the fact that the reasons applications developed is not for 'testing', and testing is not the only phase/process that goes into an application development. Applications are developed for production use. And as I explained in the 'who needs singletons' section, singletons can cut a GREAT deal from the complexity of having to make a code work WITH and INSIDE many different codebases/applications/third-party services. The time which may be lost in testing, is time gained in development and deployment. This is especially useful in this era of third-party authentication/application/integration - Facebook, Twitter, OpenID, many more and who knows what's next.

Though it is understandable - programmers work in very different circumstances depending on their career. And for people who work in relatively big companies with defined departments tending different, defined software/applications in a comfortable fashion and without the impending doom of budget cuts/layoffs and the accompanying need to do a LOT of stuff with a lot of different stuff in a cheap/fast/reliable fashion, singletons may not seem so necessary. And it may even be nuisance/impediment to what they ALREADY have.

But for those who needs to work in the dirty trenches of 'agile' development, having to implement many different requests (sometimes unreasonable) from their client/manager/project, singletons are a saving grace due to reasons explained earlier.

- Another objection is that its memory footprint is higher

Because a new singleton will exist for each request from each client, this MAY be an objection for PHP. With badly constructed and used singletons, the memory footprint of an application can be higher if many users are served by the application at any given point.

Though, this is valid for ANY kind of approach you can take while coding things. The questions which should be asked are, are the methods, data which are held and processed by these singletons unnecessary? For, if they ARE necessary across many of the requests application is getting, then even if you don't use singletons, those methods and data WILL be present in your application in some form or another through the code. So, it all becomes a question of how much memory will you be saving, when you initialize a traditional class object 1/3 into the code processing, and destroy it 3/4 into it.

See, when put this way, the question becomes quite irrelevant - there should not be unnecessary methods, data held in objects in your code ANYway - regardless of you use singletons or not. So, this objection to singletons becomes really hilarious in that, it ASSUMES that there will be unnecessary methods, data in the objects created from the classes you use.

- Some invalid objections like 'makes maintaining multiple database connnections impossible/harder'

I can't even begin to comprehend this objection, when all one needs to maintain multiple database connections, multiple database selections, multiple database queries, multiple result sets in a given singleton is just keeping them in variables/arrays in the singleton as long as they are needed. This can be as simple as keeping them in arrays, though you can invent whatever method you want to use to effect that. But let's examine the simplest case, use of variables and arrays in a given singleton:

Imagine the below is inside a given database singleton:

$this->connections = array(); (wrong syntax, I just typed it like this to give you the picture - the proper declaration of the variable is public $connections = array(); and its usage is $this->connections['connectionkey'] naturally )

You can set up, and keep multiple connections at any given time in an array in this fashion. And same goes for queries, result sets and so forth.

$this->query(QUERYSTRING,'queryname',$this->connections['particulrconnection']);

Which can just do a query to a selected database with a selected connection, and just store in your

$this->results

array with the key 'queryname'. Of course, you will need to have your query method coded for this - which is trivial to do.

This enables you to maintain a virtually infinite number of (as much as the resource limits allow of course) different database connections and result sets as much as you need them. And they are available to ANY piece of code in any given point in any given codebase into which this singleton class has been instantiated.

OF COURSE, you would naturally need to free the result sets, and connections when not needed - but that goes without saying, and it's not specific to singletons or any other coding method/style/concept.

At this point, you can see how you can maintain multiple connections/states to third-party applications or services in the same singleton. Not so different.

Long story short, in the end, singleton patterns are just another method/style/philosophy to program with, and they are as useful as ANY other when they are used in the correct place, in the correct fashion. Which is not different from anything.

You will notice that in most of the articles in which singletons are bashed, you will also see references to 'globals' being 'evil'.

Let's face it - ANYthing that is not used properly, abused, misused, IS evil. That is not limited to any language, any coding concept, any method. Whenever you see someone issuing blanket statements like 'X is evil', run away from that article. Chances are very high that it's the product of a limited viewpoint - even if the viewpoint is the result of years of experience in something particular - which generally ends up being the result of working too much in a given style/method - typical intellectual conservatism.

Endless examples can be given for that, ranging from 'globals are evil' to 'iframes are evil'. Back around 10 years ago, even proposing the use of an iframe in any given application was heresy. Then comes Facebook, iframes everywhere, and look what has happened - iframes are not so evil anymore.

There are still people who stubbornly insist that they are 'evil' - and sometimes for good reason too - but, as you can see, there is a need, iframes fill that need and work well, and therefore the entire world just moves on.

The foremost asset of a programmer/coder/software engineer is a free, open and flexible mind.