[SPRING] Spring MVC 애플리케이션의 서비스 레이어에 어떤 명명 규칙을 사용합니까? [닫은]

Spring MVC 애플리케이션의 서비스 레이어에 어떤 명명 규칙을 사용합니까? [닫은]

나는 봄 응용 프로그램에서 서비스 계층에 대한 좋은 명명 규칙을 알아내는 것에 매달렸다. 서비스 계층의 각 클래스에 대해 먼저 구현해야하는 인터페이스와 실제 클래스를 작성합니다. 예를 들어 다음과 같은 인터페이스가 있습니다.

public interface UserAccountManager{
   public void registerUser(UserAccount newUserAccount);
   public void resetPassword(UserAccount userAccount);
...
}

그리고 구현 클래스 ...

내가 여기있는 버그는 UserAccountManager가 구현 클래스에 대한 좋은 이름이므로 SimpleUserAccountManager 또는 UserAccountDbManager와 같은 어리석은 이름을 지정해야합니다. 지금까지 사용해온 컨벤션은 무엇입니까? 구현 클래스를 다른 패키지에두고 인터페이스와 동일한 이름을 지정하는 것이 좋은 생각입니까? 또한 Service로 끝나는 이름에 대해 Manager로 끝나는 이름을 사용하는 것에 대한 귀하의 생각은 무엇입니까?

해결법

1. ==============================

   1.Spring 자체는 인터페이스의 일반적인 이름을 부여한 다음 구현의 세부 사항을 기반으로 클래스의 이름을 지정합니다. 이것은 마음에 떠오르는 한 가지 예입니다.

   Spring 자체는 인터페이스의 일반적인 이름을 부여한 다음 구현의 세부 사항을 기반으로 클래스의 이름을 지정합니다. 이것은 마음에 떠오르는 한 가지 예입니다.

   interface: Controller
   abstract classes: AbstractController, AbstractCommandController, 
                     SimpleFormController, MultiActionController
   

   SimpleUserAccountManager 나 UserAccountDbManager와 같은 이름은 매니저 / 서비스의 구현에 관한 정보를 전달하기 때문에 어리 석다 고 생각하지 않습니다.

   내가 멍청하다고 느낀 것은 구현 클래스에서 "Impl"접미사를 추가하는 일반적인 규칙입니다.

   my/package/UserAccountManager
   my/package/impl/UserAccountManagerImpl
   

   어떤 사람들은 이것을 선호합니다.

2. ==============================

   2.다음은 우리가 사용하는 것입니다 :

   다음은 우리가 사용하는 것입니다 :

   구현을 위해 Impl 접미어 (XxxServiceImpl)를 추가하여 인터페이스와 구별되며 여러 구현이 있거나 추가 정보를 추가하려는 경우 접두사 (JdbcXxxDaoImpl, GoogleMapsGeocodingServiceImpl 등)로 추가합니다. 이런 식으로 클래스 이름이 약간 길어 지지만, 매우 명쾌하고 스스로 문서화됩니다.

3. ==============================

   3.예를 들어, HibernateUserAccountManager, JPAUserAccountManager 또는 JDBCUserAccountManager 등의 작업 수행 방식을 반영하는 구현 이름을 사용하거나 UserAccountManagerDAO 만 사용합니다.

   예를 들어, HibernateUserAccountManager, JPAUserAccountManager 또는 JDBCUserAccountManager 등의 작업 수행 방식을 반영하는 구현 이름을 사용하거나 UserAccountManagerDAO 만 사용합니다.

4. ==============================

   4.클래스 이름이 관리자 또는 서비스로 끝나는 지 여부는 중요하지 않습니다. 중요한 것은 일반적으로 이름이 모델링되는 것을 정확하게 전달한다는 것입니다. 이것이 바로 문제의 핵심입니다. "서비스"또는 "관리자"는 실제 소프트웨어 개체에서 모델을 시도하는 실제 개체가 아닙니다. 오히려, 우리가 필요로하거나 모델링하고 싶은 객체의 책임에 단순히 부합하지 않는 여러 가지 메소드를 수집하는 곳입니다.

   클래스 이름이 관리자 또는 서비스로 끝나는 지 여부는 중요하지 않습니다. 중요한 것은 일반적으로 이름이 모델링되는 것을 정확하게 전달한다는 것입니다. 이것이 바로 문제의 핵심입니다. "서비스"또는 "관리자"는 실제 소프트웨어 개체에서 모델을 시도하는 실제 개체가 아닙니다. 오히려, 우리가 필요로하거나 모델링하고 싶은 객체의 책임에 단순히 부합하지 않는 여러 가지 메소드를 수집하는 곳입니다.

   개인적으로 나는 "서비스"를 선호하지만, "매니저"가 실제로 모델링 할 수있는 것처럼 보이기 때문에 (즉, 우리의 "관리자"객체가 나타내는 실제 관리자가있을 수 있기 때문에). 그러나 그 요지는 완전히 학문적 인 것이고, 나는 실제적인 차이가 전혀 없다는 것을 즉시 인정합니다.

   정말로 중요한 것은 일반적으로 그러한 미세한 점보다 훨씬 기본입니다 : 개발과 관련된 모든 사람이 잘 이해할 수있는 모델을 가지기. 내 경험이 아무 것도 없다면, 드물다. "관리자"또는 "서비스"가 올바른 은유인지 묻는 사람들에게 내 조언은 다음과 같습니다. 동전 뒤집기, 모두가 대회에 대해 알고 있는지 확인하고, 중요한 문제를 숙고하고 토론하는 데 시간을 투자하십시오!

5. ==============================

   5.서비스 대 관리자 명명 접미사는 순전히 선호도라고 생각합니다. "서비스"가 우리에게 혼란을 일으키는 유일한 시간은 웹 서비스가 서비스 계층 위에 놓이는 경우뿐입니다. 일부 프로젝트에서는 단순히 웹 서비스 클래스를 브로커로 언급했습니다. 웹 서비스 클래스를 브로커로 변환하거나 브로커를 브로커 서비스 클래스로 호출하는 역할 만했기 때문입니다.

   서비스 대 관리자 명명 접미사는 순전히 선호도라고 생각합니다. "서비스"가 우리에게 혼란을 일으키는 유일한 시간은 웹 서비스가 서비스 계층 위에 놓이는 경우뿐입니다. 일부 프로젝트에서는 단순히 웹 서비스 클래스를 브로커로 언급했습니다. 웹 서비스 클래스를 브로커로 변환하거나 브로커를 브로커 서비스 클래스로 호출하는 역할 만했기 때문입니다.

   나는 "Impl"로 구현 된 접미사가 좋은 접근 방법이 아니라고 Kiniannakakis가 동의합니다. 또한이 작업을 수행하지 않는다고 언급 한 우수 사례 코딩과 관련해 왔습니다. 추상화 후 인터페이스의 이름을 지정하는 것은 일반적으로 허용되는 최상의 방법입니다. 인터페이스 뒤에 구현 클래스의 이름을 지정하는 것은 키이안 카카 (keiannakakis)가 제안한 것처럼 목적이나 유형에 대한 지표를 사용하여 일반적으로 받아 들여진 접근 방식 인 것으로 보입니다.

   웹 서비스 기반 DAO와 ORM 기반 DAO가있을 때 우리는 패키지와 클래스 이름을 사용하여 인터페이스와 구현 클래스를 구별합니다. 구현을 다른 패키지에 넣는 것은 패키지에 얼마나 많은 클래스가 있는지, 패키지가 어떻게 다르게 구현되는지, 물건을 분할하려는 정도에 달려 있다고 생각합니다.

6. ==============================

   6.인터페이스 IUserAccountManager의 이름을 지정할 수도 있습니다 (이 규칙은 Eclipse RCP에서 사용됩니다). 그런 다음 기본 구현을 위해 UserAccountManager를 사용하십시오.

   인터페이스 IUserAccountManager의 이름을 지정할 수도 있습니다 (이 규칙은 Eclipse RCP에서 사용됩니다). 그런 다음 기본 구현을 위해 UserAccountManager를 사용하십시오.

7. ==============================

   7.나에게 서비스 클래스는 유스 케이스를 구현하는 것에 관한 것이므로 서비스를 대신하는 사용자의 유형에 따라 이름을 짓는다. 따라서 다른 역할을 가진 응용 프로그램이 있고 Customer, Order Fullfillment, Data entry people 및 Admins라고하면 CustomerService, OrderFulfillmentService, DataEntryService 및 AdminService가있을 것입니다. 나는 가져 오는 데이터의 종류에 따라 서비스를 명명하는 것이 반 패턴이라고 생각한다. 그래서 UserAccount 조작이 관리자의 도메인 일 것이라고 추측하면 아마 "AdminService"라고 부릅니다.

   나에게 서비스 클래스는 유스 케이스를 구현하는 것에 관한 것이므로 서비스를 대신하는 사용자의 유형에 따라 이름을 짓는다. 따라서 다른 역할을 가진 응용 프로그램이 있고 Customer, Order Fullfillment, Data entry people 및 Admins라고하면 CustomerService, OrderFulfillmentService, DataEntryService 및 AdminService가있을 것입니다. 나는 가져 오는 데이터의 종류에 따라 서비스를 명명하는 것이 반 패턴이라고 생각한다. 그래서 UserAccount 조작이 관리자의 도메인 일 것이라고 추측하면 아마 "AdminService"라고 부릅니다.

8. ==============================

   8.관리자와 서비스의 차이점  가능한 한 오랫동안 비즈니스 로직 (서비스 계층 OR 관리자 계층)에 하나의 계층을 사용한다고 말합니다.

   관리자와 서비스의 차이점  가능한 한 오랫동안 비즈니스 로직 (서비스 계층 OR 관리자 계층)에 하나의 계층을 사용한다고 말합니다.

   해당 계층이 복잡 해지 자마자 (서비스를 사용한다고 가정) 한 서비스 또는 다른 서비스에 위임 할 책임이있는 관리자를 추가 할 수 있지만 비즈니스 로직을 서비스 내에 보관하십시오.

   따라서 서비스를 간단하게 유지하고 관리자를 사용하여 서비스를 관리하며 비즈니스 논리를 서비스 내에 보관합니다.

   또한 구현을위한 Impl 접미사를 피하고 인터페이스의 접미사를 피하는 것에 동의합니다. 예를 들어 인터페이스 "Controller"의 이름을 지정하고 "SimpleController"또는 "UserController"구현의 이름을 지정하는 것이 나에게 더 좋습니다.

9. ==============================

   9.이것들이 REST 서비스를위한 것이라고 가정 할 때, 당신의 URI 명명 규칙은 기본 구현 서비스의 이름보다 중요하다. 왜냐하면 후자는 클라이언트에게는 거의 보이지 않을 것이기 때문이다. 물론 내부적으로 일관된 이름 지정을 원하지만 중요하지는 않습니다.

   이것들이 REST 서비스를위한 것이라고 가정 할 때, 당신의 URI 명명 규칙은 기본 구현 서비스의 이름보다 중요하다. 왜냐하면 후자는 클라이언트에게는 거의 보이지 않을 것이기 때문이다. 물론 내부적으로 일관된 이름 지정을 원하지만 중요하지는 않습니다.

   우리가 사용한 일부 REST 지침 : http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html (내 블로그)

from https://stackoverflow.com/questions/995473/what-naming-convention-do-you-use-for-the-service-layer-in-a-spring-mvc-applicat by cc-by-sa and MIT license