데이터 액세스 클래스를 리더와 라이터로 분할하거나 결합 하시겠습니까?

Question

이는 '토론'측면 일 수 있지만 이에 대한 귀하의 의견을 듣고 싶습니다.

이전에는 읽기와 쓰기를 모두 처리하는 데이터 액세스 클래스를 자주 작성했는데, FooIoHandler 등과 같이 이름이 잘못 지정되는 경우가 많았습니다.좋은 솔루션입니다. 그래서 최근에 데이터 액세스를 FooWriter와 FooReader로 분할하기 시작했습니다. 이렇게하면 이름이 더 멋지고 유연성이 더해 지지만 동시에 클래스가 크지 않으면 함께 유지하는 것이 좋습니다.

독자 / 작가 분리가 더 나은 디자인입니까, 아니면 결합해야합니까?그것들을 합쳐야한다면, 클래스 이름은 무엇입니까?

감사합니다 / Erik

Answer 1

ORM이 최상의 솔루션 일 수 있습니다.
또는 상태 지속성을 담당하는 "thingContext"개체와 함께 저장소 유형 패턴을 사용합니다.

개인적으로는 저장 로직이 기본 클래스로 구워지는 activeRecord 패턴을 사용하지만 nHibernate 스타일 저장소 패턴을 선호합니다.DDD를 허용하고 db없이 테스트하는 것은 내 비즈니스 로직이 이제 새로운 UI에 대한 견인력을 얻고있는 프레임 워크 유형 상황에서 매우 유용합니다.

Answer 2

지금 Linq to Sql을 사용하고 있습니다.이것은 문제를 완전히 해결합니다.

하지만 해당 옵션 (또는 유사한 ORM 도구)이 없다면 읽기 / 쓰기 방법을 분리 할 이유가 없습니다.더 많은 클래스를 추가하고 데이터 액세스를 복잡하게 만듭니다.저는 항상 다음과 같이 설계했습니다.

1. 부품 / 사업 대상 : 자동차
2. 정적 읽기 및 쓰기 메서드를 포함하는 데이터 액세스 : CarDB

   사용 예 : 라코 디스

   이것은 읽기와 쓰기가 동일한 트랜잭션의 일부로 수행되어야하는 데이터 액세스에도 적합합니다.수업을 나누면 어디로 갈까요?

Answer 3

ORM을 무시하면 (내가 찬성하거나 반대하기 때문이 아니라) 같은 클래스에 유지됩니다.둘 다 하나의 책임의 측면이며이를 분리하는 것은 당신이 그렇게하고 싶은 좋은 이유를 정말로 생각할 수없는 두 곳에서 당신을 보게합니다.

Answer 4

백엔드 저장소에 읽고 쓰는 것을 데이터 접근 자, ReaderWriter, IO 또는 저장소라고 부를 수 있습니다.

다음 중 하나는 어떻습니까?

• FooDataAccessor
• FooAccessor
• FooReaderWriter
• FooRW
• FooIO
• FooStore
• FooStorage

Answer 5

선택권이 주어지면 일반적으로 독자를 하위 분류하여 작가를 만듭니다.