2010-12-30 6 views
1

애플리케이션 비즈니스 로직이 80 %이고 CRUD가 20 %이거나 그 반대 인 경우를 가정 해 봅시다. 비즈니스 로직 레이어를 어떻게 구현해야합니까?

은 과거에 내가 명령 패턴의 어떤 종류를 사용하고 ComplexFooCMD 또는 EvenMoreComplexBarCMD 같은 수업을했지만, 항상 InsertFoo, UpdateFoo, DeleteFooSelectFoosCMD의 무리와 UpdateSomeValuesOfFoo 또는 SelectSomeFoos의 몇 가지로 끝났다. 이 모든 것은 BLL에 살았습니다.

최근 덜 복잡한 비즈니스 로직을 애플리케이션에 나는 FooService 같은 클래스와 서비스 패턴을 사용했지만이 또한 예상 insertFoo, updateFooselectSomeFoo이 포함되어 있습니다. 모든 서비스에서 이러한 메소드를 사용하거나 프리젠 테이션 계층에 이러한 메소드를 제공하는 서비스 만 있으면 보일러 플레이트 코드가 많이 필요합니다.

CRUD 파트와 나머지 응용 프로그램에 모두 맞는 패턴이 있습니까? 아니면 응용 프로그램의 다른 부분에 다른 패턴을 사용해야합니까?

답변

0

저는 CRUD를 비즈니스 규칙으로 생각하지 않습니다.

"기본 고객에게 해당 연도의 판매량 함수 인 백분율 할인을 제공하십시오"또는 "클라이언트의 사용자 인터페이스에이 옵션을 표시하지 않음"과 같은 규칙 패턴이 있는지 확실하지 않습니다 회사의 주소는이 주 목록에 있습니다. "

비즈니스 규칙이 항상 깔끔하지는 않습니다.

+0

음, 대부분의 경우 "foo를 삽입 할 때 foo의 ID가있는 막대 삽입"과 같은 CRUD 규칙이 있지만 이러한 규칙은 db에 직접 구현 될 수 있지만 db 관리자는별로 좋아하지 않습니다. – Harima555

+0

지속성 계층 자체가 아니라 사용 사례를 알고있는 서비스 계층 내부에 속한 것과 같은 것입니다. CRUD 작업은 객체를 유지하는 방법의 메커니즘을 캡슐화해야합니다. – duffymo

0

behavior-driven development을 읽는 것이 좋습니다. 나는 그것이 당신을 올바른 방향으로 인도 할 것이라고 생각합니다.

제가 주제에 대해 읽은 책 중 가장 좋은 책은 The RSpec Book입니다.하지만 Ruby 중심의 예를 많이 보지 않으려면 다른 언어로 된 자료를보고 싶을 것입니다.

요약하면 질문에 대한 답은 다음과 같습니다. 테스트가 아키텍처를 안내하고 앱의 필수 동작이 테스트를 안내하게하십시오.

관련 문제