Spring MVC 애플리케이션에서 서비스 계층에 사용하는 명명 규칙은 무엇입니까?
스프링 애플리케이션에서 서비스 계층에 대한 좋은 명명 규칙을 찾는 데 어려움을 겪고 있습니다.서비스 계층의 각 클래스에 대해 먼저 구현해야 할 인터페이스를 작성한 다음 실제 클래스를 작성합니다.예를 들어 다음과 같은 인터페이스가 있습니다.
public interface UserAccountManager{
public void registerUser(UserAccount newUserAccount);
public void resetPassword(UserAccount userAccount);
...
}
그리고 구현 수업은...
여기서 저를 괴롭히는 것은 UserAccountManager가 구현 클래스에 대한 좋은 이름이기 때문에 SimpleUserAccountManager 또는 UserAccountDbManager와 같은 멍청한 이름을 붙여야 한다는 것입니다.당신이 지금까지 사용한 관습은 무엇입니까?구현 클래스를 다른 패키지에 넣고 인터페이스와 동일한 이름을 지정하는 것이 좋은 생각입니까?또한 서비스로 끝나는 이름보다 매니저로 끝나는 이름을 사용하는 것에 대해 어떻게 생각하십니까?
우리가 사용하는 것은 다음과 같습니다.
- XxxDAO(Data Access Object) - EntityManager, JDBC DataSource, 파일 시스템 등과 직접 상호 작용하는 역할을 담당합니다.SQL 또는 JPA-QL과 같은 지속성 논리만 포함해야 하며 비즈니스 논리는 포함하지 않아야 합니다.관리자에서만 액세스해야 합니다.
- XxxManager - 비즈니스 수준에서 엔티티를 관리하고, 일반적으로 CRUD 작업을 수행하지만 필요한 비즈니스 로직을 추가합니다.
- XxxService - 비즈니스 로직이 상주하는 계층입니다.가능한 한 문자열, int 등의 간단한 개체로 "말"해야 합니다.
- Xxx 컨트롤러 - UI 상호 작용 계층입니다.서비스와만 대화해야 합니다.
- XxxUtils/XxUtils - 도우미 상태 비저장 메서드. 시스템의 어떤 서비스에도 종속되지 않아야 합니다.이러한 독립성이 필요한 경우 유틸리티 클래스를 서비스로 변환하거나 서비스 결과를 매개 변수로 추가합니다.
구현을 위해 인터페이스와 구별하기 위해 Impl Summix(XxServiceImppl)를 추가하고, 여러 구현이 있거나 추가 정보를 추가하려는 경우 접두사(JdbcXxDaoImppl, GoogleMapsGeocodingServiceImppl 등)로 추가합니다.클래스 이름은 이 방법으로 약간 길어지지만 매우 설명적이고 자체 문서화되어 있습니다.
스프링 자체는 인터페이스에 일반 이름을 부여한 다음 구현의 세부 정보를 기반으로 클래스 이름을 지정합니다.다음은 생각나는 한 가지 예입니다.
interface: Controller
abstract classes: AbstractController, AbstractCommandController,
SimpleFormController, MultiActionController
SimpleUserAccountManager 또는 UserAccountDbManager와 같은 이름은 관리자/서비스 구현에 대한 일부 정보를 전달하기 때문에 어리석다고 생각하지 않습니다.
내가 바보라고 생각하는 것은 구현 클래스에 "Impl" 접미사를 추가하는 일반적인 관습입니다.
my/package/UserAccountManager
my/package/impl/UserAccountManagerImpl
하지만 어떤 사람들은 이것을 선호합니다.
예를 들어 HibernateUserAccountManager, JPAUserAccountManager, JDBCUserAccountManager 등 클래스가 작업을 수행하는 방식을 반영하는 구현 이름을 사용하거나 사용자 계정 관리자만 사용할 수 있습니다.DAO.
클래스 이름이 관리자로 끝나는지 서비스로 끝나는지는 분명히 그 자체로 중요하지 않습니다.일반적으로 말해서, 중요한 것은 이름이 모델링되는 것을 정확하게 전달한다는 것입니다.이것이 문제의 핵심입니다. "서비스" 또는 "관리자"는 우리가 소프트웨어 개체에서 모델로 시도하는 실제 개체가 아닙니다.오히려, 그들은 우리가 필요로 하거나 모델링하고자 하는 객체의 책임과 맞지 않는 것들을 수행하는 많은 방법들을 수집하는 곳입니다.
개인적으로 저는 "서비스"를 선호하지만, "관리자"가 실제로 모델링할 수 있는 것처럼 보이기 때문입니다. 즉, "-관리자" 개체가 나타내는 실제 관리자가 있을 수 있기 때문입니다.하지만 요점은 전적으로 학문적인 것이고 저는 그것이 실질적인 차이가 전혀 없다는 것을 즉시 인정합니다.
실제로 중요한 것은 대개 그러한 미세한 점보다 훨씬 더 기본적입니다.개발에 관련된 모든 사람들이 잘 이해하는 모델을 갖는 것.만약 제 경험이 참고가 된다면, 그것은 거의 사실이 아닙니다.따라서 "관리자" 또는 "서비스"가 올바른 은유인지 묻는 사람들에게 드리는 팁은 다음과 같습니다.동전을 던져 모든 사람들이 컨벤션에 대해 알도록 하고, 중요한 문제에 대해 곰곰이 생각하고 토론하는 데 시간을 보내세요!
저는 서비스가관리자 명명 접미사는 순전히 기본 설정입니다."서비스"가 우리에게 혼란을 야기한 유일한 시기는 웹 서비스가 서비스 계층의 맨 위에 있을 때입니다.일부 프로젝트에서는 웹 서비스 클래스를 브로커라고 부르기만 했습니다. 이들은 웹 서비스 호출을 우리의 서비스 계층에 대한 호출로 변환하거나 중개하는 역할만 했기 때문입니다.
나는 당신의 구현을 "Imple"로 접미사를 붙이는 것이 좋은 접근법이 아니라는 kgiannakakis의 의견에 동의합니다.저는 또한 이것을 하지 말라고 언급하는 코딩 모범 사례를 접했습니다.추상화 뒤에 인터페이스 이름을 지정하는 것이 일반적으로 허용되는 모범 사례입니다.kgiannakis가 제안한 바와 같이 구현 클래스의 이름을 인터페이스의 목적이나 유형을 나타내는 지표로 지정하는 것이 일반적으로 허용되는 접근 방식인 것 같습니다.
웹 서비스 기반 DAO와 ORM 기반 DAO를 사용하는 경우 패키지와 클래스 이름을 모두 사용하여 구현 클래스를 인터페이스와 서로 구별합니다.구현을 다른 패키지에 넣는 것은 패키지에 얼마나 많은 클래스가 있는지, 얼마나 다르게 구현되는지, 그리고 얼마나 많은 것을 나누고 싶은지에 달려 있다고 생각합니다.
인터페이스 이름을 IUserAccountManager로 지정한 다음(예: 이 규칙은 Eclipse RCP에서 사용됨) 기본 구현에 UserAccountManager를 사용할 수도 있습니다.
서비스 클래스는 사용 사례를 구현하는 것이기 때문에 서비스가 어떤 유형의 사용자를 대신하는지에 따라 이름을 지정합니다.따라서 고객, 주문 처리 담당자, 데이터 입력 담당자 및 관리자와 같은 다양한 역할을 가진 애플리케이션이 있다면 고객 서비스, 주문 처리 서비스, 데이터 입력 서비스 및 관리 서비스가 필요할 것입니다.저는 가져온 데이터나 뒤죽박죽인 데이터의 종류에 따라 서비스의 이름을 짓는 것은 반패턴이라고 생각합니다.따라서 사용자 계정 조작이 관리자의 도메인일 것이라고 추측하면 "관리 서비스"라고 할 수 있습니다.
관리자와 서비스의 차이와 관련하여:비즈니스 로직(서비스 계층 또는 관리자 계층)에 대해 가능한 한 한 계층을 사용하는 것이 좋습니다.
계층이 복잡해지는 즉시(서비스를 사용한 것으로 가정) 한 서비스 또는 다른 서비스에 위임하는 책임을 지는 관리자를 추가할 수 있지만 비즈니스 논리는 서비스 내부에 유지할 수 있습니다.
따라서 서비스를 단순하게 유지하고, 관리자를 사용하여 서비스를 관리하며, 비즈니스 논리를 서비스 내부에 유지할 것입니다.
저는 또한 구현을 위한 Impl 접미사를 피하고 인터페이스를 위한 I 접미사를 피하는 것에 동의합니다.예를 들어, 인터페이스 이름을 "Controller"로 지정하고 구현 이름을 "SimpleController" 또는 "UserController"로 지정하는 것이 좋습니다.
이러한 서비스가 REST 서비스를 위한 것이라고 가정하면, 기본 구현 서비스의 이름보다 URI 명명 규칙이 더 중요하다고 생각합니다. 이는 후자가 클라이언트에게는 거의 보이지 않기 때문입니다.물론 내부적으로 일관된 이름 지정을 원하지만 중요한 것은 아닙니다.
우리가 사용한 몇 가지 REST 지침: http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html (내 블로그)
언급URL : https://stackoverflow.com/questions/995473/what-naming-convention-do-you-use-for-the-service-layer-in-a-spring-mvc-applicat
'programing' 카테고리의 다른 글
| MariaDB Encryption의 가장 좋은 방법은 무엇입니까? (0) | 2023.08.28 |
|---|---|
| 텍스트 깜박임 jQuery (0) | 2023.08.28 |
| 실행문 중 PDO가 영향을 받는 행이었습니다. (0) | 2023.08.28 |
| c99와 c11의 차이 (0) | 2023.08.28 |
| Floatdoctor는 명령 프롬프트나 PowerShell 창에서 작동하지 않습니까? (0) | 2023.08.28 |