MVC 모델에서 컨트롤러는 파이프라인이고 모델은 프로세서입니다. 그러나 컨트롤러에는 여러 테이블의 다른 내용이 필요한 경우가 많습니다. 이러한 방식으로 모델에는 get_name, get_info, get_id 등 단 하나의 쿼리로 완료할 수 있는 많은 기능이 있습니다. 번거롭다고 느껴집니다. 실제로 컨트롤러를 사용할 곳에 쿼리를 작성하면 좋겠지만 이는 MVC의 규칙에 어긋납니다.
현재 아이디어는 가장 많이 사용되는 기능을 모델에 넣고 단편적인 기능은 컨트롤러에 남겨 두는 것입니다.
여러분의 의견을 들려주세요~
얇은 C, 굵은 M, C는 15줄을 넘지 마세요
사실 말씀하신 문제는 여러 프레임워크, 즉 코드를 기반으로 쿼리문을 동적으로 생성하는 Active Record 기능으로 해결할 수 있습니다. 처음에는 Rails 프레임워크에서 승격되었고 점차 다른 언어에도 구현되었습니다. 예를 들어
으아아아실제로 프레임워크가 활성 레코드를 지원하는 경우 기본 키를 기반으로 하는 간단한 쿼리를 위해 모델에 코드 줄을 작성할 필요가 없습니다. 호출하는 메서드 이름 및 쿼리 결과를 반환합니다.
어떤 언어를 사용하고 있는지는 모르겠지만 기본적으로 모든 스크립팅 언어에는 현재 활성 레코드 구현이 있습니다. 자신의 프로젝트에서 이 기능을 구현할 수 있으며 이는 후속 개발에도 도움이 됩니다.
모든 개발자의 레벨이 동일하다고 보장할 수는 없기 때문에 일부 디자인 원칙을 규정하는 것보다 코드에서 제한할 수 있는 문제가 더 효과적입니다.
파울러의 패턴북, 트랜잭션 스크립트, 테이블 모듈, 도메인 모델 3가지 스타일을 참고하실 수 있습니다.
CI에서 활성 레코드를 구현하는 방법은 모르겠지만 말씀하신 작은 함수는 많은 PHP 활성 레코드 구현에서 사용되는 매직 메서드이거나 코드 생성기가 자동으로 생성하므로 직접 작성할 필요가 없습니다. .
예를 들어 활성 레코드는 다음과 같이 교리에서 구현됩니다. bar1, bar2 및 bar3 필드가 있는 foo 테이블이 있는 경우 교리는 테이블 스키마에 따라 FooTable.class.php, FooTableBase.class라는 4개의 파일을 직접 생성합니다. php, Foo.class.php, FooBase.class.php. 두 기본 파일에는 getBar1(), setBar1($param)과 같이 자동으로 생성된 일련의 getter 및 setter가 있습니다. 기본 파일은 프로그래머가 직접 수정할 수 없으며 스키마가 변경되면 변경됩니다. 기본 클래스가 아닌 클래스는 기본 클래스를 직접 상속하므로 훨씬 깔끔해 보입니다
모델에 애플리케이션 로직을 추가하세요
레이어링을 해보겠습니다. 컨트롤러는 페이지 수준 제어 로직을 담당합니다
ㅋㅋㅋㅋㅋㅋ