0

안녕 얘들 아. 마틴 파울러 (Martin Fowler)의 PoEA를 읽고 있습니다. 데이터 매퍼 패턴이 방법으로 도메인 객체와 함께 일하고있다 :데이터 맵퍼가 도메인 모델을 참조해야합니까?

class AbstractMapper... 

    protected DomainObject load(ResultSet rs) throws SQLException { 
     Long id = new Long(rs.getLong(1)); 
     if (loadedMap.containsKey(id)) return (DomainObject) loadedMap.get(id); 
     DomainObject result = doLoad(id, rs); 
     loadedMap.put(id, result); 
     return result; 
    } 
    abstract protected DomainObject doLoad(Long id, ResultSet rs) throws SQLException; 

class PersonMapper... 

    protected DomainObject doLoad(Long id, ResultSet rs) throws SQLException { 
     String lastNameArg = rs.getString(2); 
     String firstNameArg = rs.getString(3); 
     int numDependentsArg = rs.getInt(4); 
     return new Person(id, lastNameArg, firstNameArg, numDependentsArg); 
    } 

그것은 데이터 매퍼 DAL 참조 도메인입니다 것을 의미한다. 나는 DAL이 그런 언급을해서는 안된다고 생각했다. 어떻게 생각해?

답변

2

프리젠 테이션 계층이나 데이터 액세스 계층을 비롯한 모든 계층에서 도메인 모델을 참조 할 수 있습니다. 그러나 도메인 모델은 이러한 레이어를 참조하지 않아야하므로 대체 인터페이스와 지속성 전략을 지원하기 위해 잠재적으로 다시 사용할 수 있습니다.

+0

답장을 보내 주셔서 감사합니다. 도메인에서 DAL을 참조하지 않으면 어떻게 사용합니까? 아마도 DAL을 직접 참조 할 필요는 없지만 데이터 소스로 작업 할 수있는 인터페이스가 필요합니다. – Danil

+0

DAL은 도메인이 아닌 도메인 개체를 유지해야합니다. 따라서 도메인 개체 중 하나가 고객 개체 인 경우 DAL에서 Customer 엔터티를로드하고 저장하는 메서드가있는 CustomerRepository와 같은 항목이있을 수 있습니다. 나는이 논리가 도메인 자체에 통합 된 것을 보았습니다. 그래서 이것이 프로젝트를 구성하는 진정한 방법 중 하나라고 말하지는 않지만, 저에게는 훨씬 깨끗해 보입니다. – newdayrising

+1

흠, 리포지토리는 도메인 개체와 함께 작동하므로 도메인 논리 인 도메인 개체의 메서드에 액세스 할 수 있습니다. 물론 이러한 방법은 리포지토리에 사용되어서는 안된다는 것이 분명합니다. 그러나 인 캡슐 레이션은 없습니다. 어쩌면 DAL의 비즈니스 로직을 캡슐화하기 위해 저장소에 인터페이스를 사용해야 할 필요가 있을까요? – Danil