최근에 싱글 톤 패턴에 대해 조금 읽었습니다. 기술적 측면을 읽을 때, 데이터베이스 핸들러 등을 관리하는 데 이상적입니다. 그러나 더 넓은 리소스를 읽은 후에는 개발자 커뮤니티가 실제로 그 패턴을 선호하지 않는 것처럼 보입니다.싱글 톤 PHP - 데이터베이스 핸들러
한 번에 하나의 처리기 만 초기화 할 수있는 문제에 대해 더 나은 해결책을 찾기 위해 애쓰는 중입니다. 그렇다면 왜 패턴이 그렇게 나쁜 것입니까? 남용되었거나 근본적으로 결함이 있습니까?
PHP는 내가 사용하는 언어입니다.
사람들은 전역 변수와 같기 때문에 Singletons가 악의적이며 코드를보다 강력하게 결합하고 테스트하기가 더 어렵습니다.
나는 그다지 나쁜 생각이 아니라고 생각하며, Singleton은 데이터베이스 처리기에서 잘 작동한다고 생각합니다. 쉽고 직관적이며 전역 변수보다 Singleton 인스턴스를 더 많이 제어 할 수 있습니다.
Singletons are glorified global variables. 디자인 패턴은 전역 변수가 어렵거나 불가능한 언어 또는 나쁜 실행으로 간주되는 언어에 맞게 만들어졌습니다. 실제로 대부분의 일반적인 디자인 패턴은 제한된 언어 용으로 설계되었으며 대부분 다른 언어에서는 불필요합니다.
PHP에는 전역 변수가 있습니다. PHP 전역 변수는 일반적으로 나쁜 습관이지만, 필요하다면 존재합니다.
그러나 PHP에서 싱글 톤을 원한다면 몇 가지 이유가 있습니다.
싱글 톤은 getInstance (싱글 톤의 단일 인스턴스를 반환하는 메서드의 정식 이름)을 호출 할 때 스크립트의 어느 지점에서나 만들 수 있습니다. 그 시점까지는 객체가 존재할 필요가 없습니다. 객체가 대신 전역 변수 인 경우 이미 존재해야하거나 객체를 참조하려는 코드가 먼저 객체를 인스턴스화해야합니다. 실제로, 그것이 사용될 수있는 곳이라면, 올바르게 인스턴스화 될 필요가 있습니다. getInstance에 단일 개체 생성을 중앙 집중화함으로써 개체를 참조해야 할 때마다 복사하여 붙여 넣기하는 상용구를 작성하지 않아도됩니다.
데이터베이스 개체 보통은 요청 수명에서 매우 일찍 생성되므로 Singleton-ness의 특정 이점이 낭비됩니다.
다른 방법으로 작업을 수행 할 수있는 Singleton의 다른 대안이 있습니다. 예를 들어, dependency injection은 새로운 객체가 생성하는 외부 객체 (예 : 데이터베이스 핸들)를 객체에 전달할 때 사용하는 멋진 용어입니다. 그러나 이것은 복잡하거나 성가심 일 수 있습니다. 이 작업을 올바르게 수행하려면 같은 개체를 매번 주입해야합니다.
또 다른 대체 방법은 Registry pattern입니다.이 방법은 사실 전역 변수가되는 항목의 컨테이너입니다. 전역 변수가 마음에 들지 않지만 효과적으로 네임 스페이스가되는 것을 꺼리는 경우, 이는 원하는 해결책이 될 것입니다.
마지막으로 코드를 작성하는 한 가지 방법을 선택하고 코드베이스 전체에 일관되게 적용하십시오. 개인적으로 저는 데이터베이스 객체의 팬입니다.
싱글 톤 패턴에는 아무 문제가 없으며 항상 사용합니다.
당신이 말한 것처럼, 리소스에 이상적입니다. 응용 프로그램에 대해 하나의 인스턴스 만 있고 전역 적이어야합니다.
일부 개발자는이 방법으로 만들 수있는 종속성으로 인해 개발자가 마음에 들지 않는다고 생각합니다. Dependency Injection에 대한 기사를 읽으십시오. Singleton이 나쁜 이유는 여기에서 다루지 만 정확하게 기억할 수는 없습니다.
대부분의 작은 웹 응용 프로그램에 싱글 톤 데이터베이스 처리기를 사용합니다. 외부 구성 파일 및 PDO를 데이터베이스 액세스 방법으로 결합하면 메소드가 응용 프로그램 모델과 관련이없는 한 (즉, getTick 또는 getBreakfast 대신 getRow 또는 getAll) 매우 유연하게 프로젝트간에 이동할 수 있습니다. . 난 그냥 내 모든 액세스 상수가 별도로 정의되었는지 확인하십시오.
싱글 톤에 대한 많은 억지는 주로 PHP보다 복잡한 언어에서 주로 파생됩니다.
이 설정 파일을 설정 파일과 연결하는 방법에 관심이 있습니다. – Bill
@Bill - 제가 디자인 한 대부분의 응용 프로그램이 전면 컨트롤러 패턴을 향합니다. http://www.oreillynet.com/pub/a/php/2004/07/08/ front_controller.html - 기본적으로 프론트 컨트롤러가로드 되 자마자 데이터베이스 액세스 권한을 상수로 만들 수있는 수많은 define 문을 포함하는 config.php 파일을 포함시킬 수 있습니다.그런 다음 모든 모델 (데이터베이스 처리기 자체도 포함됨)이 포함되어 있으므로 응용 프로그램의 모든 부분이 해당 항목의 한 지점에서 내려올 때마다 해당 처리기를 사용하여 데이터베이스 쿼리를 수행 할 수 있습니다. – DeaconDesperado
전역 변수와 별도로 커뮤니티는 싱글 톤을 싫어합니다. 결국 클래스의 추가 인스턴스가 필요할 것이기 때문입니다. 예를 들어, 데이터베이스 연결에 싱글 톤을 사용할 수 있으며, 한 번에 2 개의 데이터베이스에 연결할 때까지 작동합니다. 그 시점에서 전체 앱을 리팩터링하거나 싱글 톤을 새로운 클래스에 복사하여 붙여넣고 사용합니다. 어느 쪽이든 당신은 외륜없이 특정 개울에 가야합니다.
그러나 싱글 톤 패턴은 구현이 아닌 디자인 패턴입니다. 아무도 당신을 하나의 인스턴스로 제한하는 코드는 클래스 내에 있어야한다고 말한 사람은 없습니다. 나는 factory 메소드를 통해 클래스를 인스턴스화하면 팩토리 메소드에 싱글 톤 구현을 넣을 수 있다는 것을 발견했다. 그런 다음 언젠가 새로운 인스턴스가 필요하면 클래스 자체에 아무런 제약이 없으므로 새로운 팩토리 메소드를 추가하여이를 수행 할 수 있습니다. 물론이 가격은 항상 싱글 톤을 공장이 아닌 직접 인스턴스화하는 것입니다.
DALMP (http://code.google.com/p/dalmp/)
는 싱글 톤을 사용하고, 일부 캐시를 사용하는 경우 데이터베이스 연결이 필요하지 않은 일이 발생할 수 있습니다
2 개 이상의 데이터베이스에 동시에 연결할 수있는 기능을 가지고있다. 또한 싱글 톤은 클래스에서 사용되므로 자동로드를 사용할 수 있습니다. Singleton이 PHP에서 데이터베이스 처리에 좋지 않다고 나는 믿지 않는다. – Savageman
매우 사실입니다. 코드와 데이터베이스 사이에 포괄적 인 캐싱 계층이 있다면 적어도 어느 정도는 연결을 열 필요가 없을 수도 있습니다. – Charles
테스트에 대한 요지는 매우 유효합니다. 싱글 톤의 가장 큰 문제점은 단일 인스턴스 (dbs를 분리하는 데 두 개의 별도 db 연결은 어떻게됩니까?)뿐만 아니라 특정 구현에만 제한된다는 것입니다. 테스트하고 싶다면 db 연결을 다른 것으로 바꿔야합니다. 추상화는 싱글 톤을 확장 할 수 없으므로 더욱 어려워집니다. 레지스트리는 이러한 많은 문제를 해결합니다. – igorw