서비스 클래스를 만들려면

언제 ConfigurationService라는 비즈니스 서비스를 생성해야합니까?서비스 클래스를 만들려면

서비스의 논리가 데이터베이스 또는 파일 시스템에 액세스 할 수 있습니까?

클래스는 언제 서비스됩니까?

데이터베이스 액세스가 없으므로 ConfigurationReader가 아닌 ConfigurationReader를 xml 파일로 읽는 중입니까?

2014-12-12 Pascal

이 질문은 _service_를 정의하는 방법에 따라 달라집니다. – Gusdor

@ Gusdor하지만 이것은 내 문제입니다. 서비스는 추상적이지만 비즈니스 로직을 수행합니다. 그러나 기업도이를 수행 할 수 있습니다. 다른면에서 엔티티는 현실 세계의 객체입니다 (그러나 항상 그렇지는 않습니다) 서비스는 실제 세계의 객체와 아무 관련이 없습니다 (흠 ... 나는 사실도 알지 못합니다). 그렇다면 일부는 엔티티가 데이터베이스 무신론자라고 말하고 서비스는 때때로 데이터베이스에 의존하지 않는다고 말합니다. 나는 계속할 수있다 ... – Pascal

일반적으로 은 도메인 객체와 서비스를 상태 비 저장한다는 점을 구분합니다. 종종 (항상 그런 것은 아니지만) 주 (데이터베이스 또는 파일 시스템과 같은)의 소스에 액세스 할 수 있지만 스스로 포함하지는 않습니다.

따라서 ConfigurationReader가 전달 된 XML에서 구성을 읽고 해당 구성을 로컬 변수에 유지하면 도메인 개체입니다. 구성을 읽고 구문 분석 된 구성 개체를 반환하면 서비스입니다.

위의 설명과 마찬가지로, 이것은 모든 의미이며 다른 사람들의 정의는 크게 달라질 수 있습니다.

출처

2014-12-12 16:01:32

dataprovider로부터 값 비싼 값을 얻기를 원하지 않는 캐싱 데이터가 있기 때문에 서비스가 항상 stateless가되는 것은 아니다. "... 크게 달라질 것입니다 ..."즉 대답이 없다는 의미입니까? :/ – Pascal

캐싱은 상태 저장과 매우 다른 관심사입니다. 그리고 스케일링 문제가 매우 다릅니다. 캐싱에서 데이터는 존재하지 않을 수 있지만 작업은 성공하지만 (더 느리지 만) 상태 저장소에서는 서비스가 성공하기 위해 데이터를 필요로합니다. –

서비스 캐시를 "상태 저장"으로 간주하지 않습니다. 또한 서비스 계층이 아닌 DAO 계층에 캐싱을 유지하려고합니다. 따라서 서비스 계층에 캐싱이 더 보이지 않게되고 데이터 관점에서 볼 때 올바른 위치에 데이터 액세스가 이루어집니다. –

서비스 클래스를 만들려면

답변

관련 문제