Problem Statement
연관: #84
현재 테스트를 위해 코드베이스를 읽어보고 있는데, 인자로 Libvirt.* 가 직접적으로 넘어가는 경우가 굉장히 많습니다.
(e.g., Libvirt.Connect) 성능적인 측면이나 테스트를 위해선 libvirt 가 매번 호출되는 것이 아니라 libvirt 에 대한 접근은 인터페이스 등으로 추상화
되고, 메소드만이 노출되는 것이 좋아보입니다.
libvirt.Connect.GetALLInstance()를 호출해야 되는 경우가 있다면,
libvirt.Connect 가 전달돼서 메소드가 호출되는 것이 아니라, InstanceGrapper 가 호출되어서 vm의 리스트를 전달하는 것이 낫다는 의미.
현재처럼 구조체를 직접적으로 참조하거나 인자로 넘어오는 경우 테스트 만들때도 빡세고 추후에 확장할때도 쉽지 않습니다.
(하나의 구조체가 모든 메소드를 포함하면 분리할 수 없음)
Proposed Solution
libvirt 를 DB와 같은 단일 소스라고 생각한다면, libvirt 에 대한 접근은 적절히 추상화 되어 서비스 로직 단위로 인터페이스를 만드는게 적절해보입니다.
적용 대상:
libvirt.Domain
libvirt.Connect
Alternatives Considered
Problem Statement
연관: #84
현재 테스트를 위해 코드베이스를 읽어보고 있는데, 인자로 Libvirt.* 가 직접적으로 넘어가는 경우가 굉장히 많습니다.
(e.g., Libvirt.Connect) 성능적인 측면이나 테스트를 위해선 libvirt 가 매번 호출되는 것이 아니라 libvirt 에 대한 접근은 인터페이스 등으로 추상화
되고, 메소드만이 노출되는 것이 좋아보입니다.
libvirt.Connect.GetALLInstance()를 호출해야 되는 경우가 있다면,libvirt.Connect 가 전달돼서 메소드가 호출되는 것이 아니라, InstanceGrapper 가 호출되어서 vm의 리스트를 전달하는 것이 낫다는 의미.
현재처럼 구조체를 직접적으로 참조하거나 인자로 넘어오는 경우 테스트 만들때도 빡세고 추후에 확장할때도 쉽지 않습니다.
(하나의 구조체가 모든 메소드를 포함하면 분리할 수 없음)
Proposed Solution
libvirt 를 DB와 같은 단일 소스라고 생각한다면, libvirt 에 대한 접근은 적절히 추상화 되어 서비스 로직 단위로 인터페이스를 만드는게 적절해보입니다.
적용 대상:
Alternatives Considered