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

Question

"discussiony"쪽에 있을지 모르겠지만이 점에 관해 여러분의 의견을 듣고 싶습니다.

이전에는 종종 FooIoHandler와 같이 가난한 이름 지정으로 이어지는 읽기 및 쓰기를 처리하는 데이터 액세스 클래스를 작성했습니다. 아마도 이름을 지정하기 힘든 클래스는 잘못 설계된 것으로 어림짐작은 이것이 아니라고 제안합니다 좋은 해결책.

그래서 최근 데이터 액세스를 FooWriter 및 FooReader로 분할하기 시작했습니다. FooWriter와 FooReader는 더 유연한 이름을 제공하고 유연성을 추가하지만, 동시에 클래스를 크게 유지하지 않으면 .

리더/라이터 분리가 더 나은 디자인입니까? 아니면 결합해야합니까? 내가 그들을 결합해야한다면, 내가 그 반원의 이름을 무엇이라고해야합니까?

감사합니다/에릭

Answer 1

ORM은 최선의 솔루션이 될 수 있습니다.
상태 지속성을 담당하는 "thingContext"객체와 함께 저장소 유형 패턴을 사용하십시오.

개인적으로 저는 saveRecord 패턴을 사용합니다. 여기서 save 로직은 기본 클래스로 구워졌지만 nHibernate 스타일 저장소 패턴을 선호합니다. DDD를 허용하고 DB가없는 것들을 테스트하면 프레임 워크 유형의 상황에서 비즈니스 로직이 새로운 UI를 찾고 있습니다.

Answer 2

저는 Linq to Sql을 사용하고 있습니다. 이렇게하면 문제가 완전히 해결됩니다.

그러나 옵션 (또는 유사한 ORM 도구)이없는 경우 읽기/쓰기 메소드를 분리 할 이유가 없습니다. 더 많은 클래스를 추가하고 데이터 액세스를 복잡하게 만듭니다.

1. 구성 요소/비즈니스 개체 : 난 항상 다음과 같이 설계 한 자동차
2. 데이터 액세스를 정적 ​​읽기 포함 및 쓰기 방법 : CarDB

사용 예 :

Car car = new Car(); 
car.Manufacturer = "Toyota" 
car.Model = "Camry" 
car.Year = 2006; 
car.CarID = CarDB.InsertCar(car) 
car.OwnerID = 2; 
CarDB.UpdateCar(car); 

이는 동일한 트랜잭션의 일부로 Read와 Write가 모두 수행되어야하는 데이터 액세스에도 의미가 있습니다. 수업을 나누면 어디로 갈까요?

Answer 3

나는 ORM을 무시하고 (나는 그것 때문에 또는 반대이기 때문에) 나는 같은 계급에서 그들을 지킬 것이다. 그것들은 단 하나의 책임의 양면이고 그들을 분리하는 것은 당신이 그것을하고 싶어하는 좋은 이유를 정말로 생각할 수없는 두 장소를 보게합니다.

Answer 4

필자는 필자에게 일반적으로 독자를 서브 클래스 화하여 작성자를 작성합니다.

Answer 5

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

어떻게 약 하나

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