PHP pdo实例作为私有静态属性 [英] PHP pdo instance as private static property
问题描述
我尝试根据OOP设计我的网站，但我在设计数据库连接时遇到问题。目前，我在抽象类Connector中创建一个私有静态PDO对象。显然，任何需要与数据库交互的东西都会扩展这个类。我一直在翻转，如何确保在脚本中只有一个连接或PDO对象，因为一些页面将需要多个类，扩展连接器。很多人似乎推荐一个单例模式为这个目的，但我目前的方式似乎完成同样的事情。
这是我当前的代码。
抽象类连接器
{
private static $ dbh;
public function __construct（）
{
try
{
self :: $ dbh = new PDO（...）;
self :: $ dbh-> setAttribute（PDO :: ATTR_ERRMODE，PDO :: ERRMODE_EXCEPTION）;
}
catch（PDOException $ e）
{
die（$ e-> getMessage（））;
}
}
public function getDB（）
{
return self :: $ dbh;
}
}
然后任何子类都会这样使用。 p>
class Subclass extends Connector
{
public function interactWithDB（）
{
$ stmt = $ this-> getDB（） - > prepare（...）;
// etc ...
}
}
理论上，每个子类的实例应该总是访问相同的PDO实例，我想。这个代码实际上是有意义的，或者我是以某种方式误解静态属性吗？
如果某些东西不清楚，请留下评论。
EDIT：
Connector类不仅仅用于保存PDO对象。它是析构函数关闭连接（使它为null），它包含函数isValueTaken，它检查一个值是否已经在数据库中。它有以下抽象函数
抽象函数retrieveData（）;
abstract function setData（）;
例如，我有一个扩展Connector的User类。它定义setData（）在数据库中注册一个用户。
显然，任何东西需要与数据库交互才能扩展这个类。
从OOP的角度来看，这真的没有意义。当一些类扩展另一个意味着是一个关系的类。如果你走这条路线，你会有一个困难的时候不违反 OCP 这是一个的 SOLID 中的字母。
我一直在翻转，如何确保在脚本中只有一个连接或PDO对象，因为一些页面将需要多个类
轻松！只需创建一个实例。
许多人似乎推荐一个Singleton模式为此目的，但我目前的方式似乎完成同样的事情。
很多人喜欢这一点，没有关于OOP原则的线索。使用单例只是引入了一个奇特全局实例/状态
这段代码是否有意义，或者是我误解了静态属性？
老实说，这是对OOP的误解。
实践和/或Singleton有更多的优势吗？
您应该做什么（在OOP中）是注入数据库连接进入需要它的类。这使得您的代码松散耦合，这反过来使您的代码更好的可维护性，可测试性，可调试性和灵活性。
此外，我真的不知道为什么需要创建数据库类用于pdo连接，因为PDO API本身已经是OOP。因此，除非你有一个真正的理由写一个适配器（可能是这种情况，因为有一些）PDO我会放弃它。
我的€0.02
-
回应您的编辑：
< >
Connector类不仅仅用于保存PDO对象。它是析构函数关闭连接（使它为空）。
通常不需要关闭连接。
并且它包含的功能如isValueTaken ，它检查值是否已经在数据库中。它有以下抽象函数
这听起来像另一个类的工作。
例如，我有一个扩展Connector的User类。它定义setData（）在数据库中注册一个用户。我不知道这是否会对回应产生影响。
没有我的观点。用户不需要继承数据库。这不是听起来很奇怪。从数据库继承的用户（我不想满足那个人）。如果需要，您应该将数据库连接注入用户。
I'm attempting to design my website based on OOP, but I'm having trouble with how to design the database connection. Currently, I'm creating a private static PDO object in an abstract class, Connector. Obviously, anything that needs to interact with the database will extend this class. I've been flipping back and forth on how to make sure that there is only ever one connection, or PDO object, in a script because some pages will need more than one class that extends Connector. Many people seem to recommend a Singleton pattern for this purpose, but the way I currently do it seems to accomplish the same thing.
Here's my current code.
abstract class Connector
{
private static $dbh;
public function __construct()
{
try
{
self::$dbh = new PDO(...);
self::$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
}
catch(PDOException $e)
{
die($e->getMessage());
}
}
public function getDB()
{
return self::$dbh;
}
}
Then any subclasses would use it like this.
class Subclass extends Connector
{
public function interactWithDB()
{
$stmt = $this->getDB()->prepare(...);
// etc...
}
}
Theoretically, each instance of a subclass should always be accessing the same PDO instance, I think. Does this code actually make sense and or am I misunderstanding static properties somehow? Is it bad design/practice and or does Singleton have more advantages?
Comment if something's not clear, thanks!
EDIT:
The Connector class wasn't meant to exist just to hold the PDO object. It's destructor closes the connection(makes it null) and it contains functions such isValueTaken, which checks if a value is already in the database. It has the following abstract functions
abstract function retrieveData();
abstract function setData();
For example I have a User class that extends Connector. It's defines setData() to register a user in the database. I don't know if this makes a difference to the response.
Obviously, anything that needs to interact with the database will extend this class.
This really makes no sense from an OOP perspective. When some class extends another class that implies an "is a" relationship. If you go this route you are going to have a hard time not violating OCP which is one of the letters in SOLID.
I've been flipping back and forth on how to make sure that there is only ever one connection, or PDO object, in a script because some pages will need more than one class that extends Connector.
Easy! Just create one instance.
Many people seem to recommend a Singleton pattern for this purpose, but the way I currently do it seems to accomplish the same thing.
Many people like that have no clue about OOP principles. Using an singleton just introduces a "fancy" global instance / state.
Does this code actually make sense and or am I misunderstanding static properties somehow?
To be honest it is more a misunderstanding of OOP.
Is it bad design/practice and or does Singleton have more advantages?
See above.
What you should do (in OOP) is inject the database connection into the classes that need it. This makes your code loosely coupled which in turn makes your code better maintainable, testable, debuggable and flexible.
Also I don't really see why you need to create a database class for a pdo connection, because the PDO API itself is already OOP. So unless you have a real reason to write a adapter (can be the case, because there are some) for PDO I would just drop it.
My €0.02
--
In response to your edit:
The Connector class wasn't meant to exist just to hold the PDO object. It's destructor closes the connection(makes it null).
There is often no need at all to close the connection. The connection will automatically be closed once the request is handled (unless we are talking about a persistent connection).
and it contains functions such isValueTaken, which checks if a value is already in the database. It has the following abstract functions
That sounds like a job for another class.
For example I have a User class that extends Connector. It's defines setData() to register a user in the database. I don't know if this makes a difference to the response.
No my point still stands. There is no need for a user to inherit from a database. Doesn't that sounds strange. A user inheriting from a database (I don't want to meet that person). You should inject the database connection into the User if it is needed.
这篇关于PHP pdo实例作为私有静态属性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
