클래스에 MySQL select 문을 넣고 하위 클래스에 CRUD 문을 넣을 필요가 있습니까?

Question

데이터베이스에 액세스하는 데 2 ​​개의 클래스가 있습니다.

"select"문을 사용하는 데이터베이스 만 MovieDAO에 액세스합니다. 그 목적은 웹 브라우저에 표시 할 데이터를 검색하는 것입니다. 더 완전한 인 및// 업데이트를 만드는 상속 된 기능 이외에 동영상을 삭제 가능 -

및

MovieExtendedDAO은 (MovieDAO를 확장). 이 클래스는 사이트의 관리 영역에서만 사용하도록되어 있습니다.

나는 이것을 이와 같이 분리하는 것이 과잉이라고 들었다.

정상적인 방법일까요, 아니면 디자인 패턴의 일부입니까? 아니면 이것을하는 데 실질적인 도움이되지 않습니까? 나의 주된 의도는 대중에게 필요한 것들을 단순화하는 것이 었습니다. 얼마나 많은 물건을 적재해야하는지에 대한 최적화와 공공 (비 관리자) 측에서 어떤 일이 발생할 수 있는지에 대한 최적화였습니다. 의견을 보내 주셔서 감사합니다.

Answer 1

나쁜 방법은 아니며 기본적으로 row data gateway입니다. 그 의미에서 나는 movieDAO를 파인더 (fowler와 동일한 용어)와 게이트웨이 (예 : MovieFinder 및 MovieGateway)로 더 많이 생각할 것입니다.

일단 복잡한 도메인 논리 (예 : 영화에 대한 다양한 계산)를 시작한 후에는 다른 데이터 액세스 패턴을 볼 수는 있지만 접근 방법이 합리적인 것처럼 보입니다.

Answer 2

왜 클래스를 분리하는지 고려해야합니다. 성능 향상을 위해 (단순한 읽기를 위해 더 큰 클래스를로드하지 않기 위해), 가장 확실하게 조기에 최적화하는 것보다. 실제 데이터에서 그러한 필요성이 있음을 알릴 때까지는 그러한 결정을 내려서는 안됩니다 (내 의견으로는 결코 일어나지 않을 것입니다. 대형 클래스에 대해 걱정할 경우 APC 또는 다른 바이트 코드 캐시를 사용하십시오).

권한에 관한 - 이것은 응용 프로그램 논리이어야하며 물리적으로 다른 클래스로 메서드를 분리하지 않아야합니다. 또한 이러한 작업을 추상화하는 기본 DAO를 확장하지 않습니까? 각 모델에 별도의 삽입/삭제/업데이트 메소드를 구현하지 않겠습니까? 이러한 작업은 많이 변하지 않으며 공통 상위 클래스에 속해야합니다.

Zend_Db과 같이 PHP에서 데이터베이스 추상화를위한 훌륭한 오픈 소스 구현을 살펴볼 것을 제안합니다.

Answer 3

과용되지 않습니다. 물론 코드에 대한 액세스를 제한하는 더 좋은 방법이 있습니다. 그러나 당신이하는 일은 데이터 (레코드의 배열)를 데이터 (단일 레코드, 인스턴스)를 수정하는 것으로부터 분리하는 것입니다.

아마도 여러분은 클래스에 다른 의미를 부여 할 수 있습니다. MovieDAO 대신 MovieQuery를 사용할 수 있으며 MovieExtendedDAO 대신 Movie를 사용할 수 있습니다. 당신은 펑크를 유지합니다. 지금은 별개이지만 수업을 좀 더 자명하게 만드십시오.

Answer 4

여기에서 볼 수있는 주된 문제는 사용 권한 (제어)와 데이터베이스 액세스 (모델)을 혼합하는 것입니다. 나는 모델 -보기 - 컨트롤러 아키텍처에 반대하지만 모든 사람들이 그것을 사용해야한다고 말하고있는 것은 아닙니다. 복잡한 패턴의 일종입니다. 그것은 당신의 솔루션에 비해 장점이있을 수 있습니다. 권한 변경으로 클래스 모델에 영향을 줍니까? 나는 그렇게 생각한다.

MVC에서 액세스 다른 방법으로 액세스를 제어 할 수 있습니다. 데이터베이스에서 (예를 들면, 사용자에 의해).