spring3.1 framework으로 standard한 웹 구성을 어떻게 하는지 좀 알려주세요. 여러가지 dao나
servlet은 어느정도 알겠고 조합해서 사용할수 있겠는데 현업에서 사용하는 구조나 샘플아키텍처구조가 있으면 좀 알려주세요..
홀로 공부하는것이랑 현업에서 사용하는 아키 구조는 다를것 같아서요.

도움이 될러지 모르겠지만... 전 2.5를 사용했습니다.

 EAR - Utility Project - dao
                               - biz
         -Dynamic Web Project - service
                                           - controller
대충 이렇게 구현했네요... controller에서 요청 하면 서비스로 보내고, 서비스에서 비즈 , 비즈에서 dao
막상 적고나니 질문에 맞는 대답인지 모르겠네요 ;;ㅎㅎ

On 2월10일, 오후11시23분, 청국장 <kcy0...@naver.com> wrote:

이 부분은 각 개발사 혹은 팀마다 다를 수 있을 것 같네요. 딱 standard한 답은 없을 것 같구요.

제 경우에는....

솔루션패키지/모듈/domain
                           /controller
                           /service
                           /dao

위의 형태로 구성합니다. 모듈이 많아지면 위의 구조를 가지는 패키지가 늘어나겠죠.
dao와 service는 interface - class 구조로 인터페이스 단을 앞에 세움으로써 뒤의 실제 로직을 숨기는 형태로
개발합니다.
domain은 데이터를 담는 모델 데이터 빈이 담겨져 있습니다. (모듈 단위로 모델 데이터 빈을 묶기도 하고, 솔루션패키지 하위에
묶기도 합니다.)

각 패키지의 내부에 위치하는 클래스들은 개발/설계 방법론에 따라 조금씩 달라질 것 같은데요. 역시 제 경우에는
최근에 도메인 주도 개발 방법론을 적용하여 여러가지 시도를 하고 있습니다.

조금 더 감을 잡으시기 위해서는 가장 기본적인 spring MVC 관련 내용을 확인해 보시고, 그외에도 여러가지 패턴이나
개발 방법론들을 둘러보시면 도움이 되실 것 같습니다.

이상 허접한 답변 드렸습니다...^^

답글은 아니구요 ^^; 사실 저도 궁금했던 부분이고 지금도 그러합니다.
책만 보다보면 스프링을 사용한 서비스 구성에는 ... 정말.. 이방법 저방법 .. 너무 많아요.

해서 가끔생각했던게
'누가 ..좀... 노멀한 구조..구성? ...의 틀을 좀 잡아줬으면 좋겠다'
라는 생각도 했었습니다.

이런 부분에 대한 글이나 ... 읽을만한걸 보신분 있으실까요? (이거 오히려 질문이 되어버렸군요 ㅎㅎㅎ )

On 2월10일, 오후11시23분, 청국장 <kcy0...@naver.com> wrote:

일단 ORM은 하이버네이트나 MyBatis(아니면 iBatis)는 기본으로 들어갈테고...

메이븐으로 jar파일 관리하니까 메이븐도 필수인데다가 웹MVC면은 Spring Security도 기본포함이겠네요...

사실 제가 사용하는 구성이 위의 구성이긴한데... 만들 때는 몰라도 테스트 할 때 정말 난감하더라구요.

JUnit과 목오브젝트를 이용해서 테스트환경을 구축해야 하는데

일반 어플리케이션이면 몰라도 웹어플리케이션은 폴더환경이 어지러워서.....

테스트환경이 뒤죽박죽이되곤 합니다;;;

스프링의 장점이 다양성이긴 한데.. 솔직히 비슷한 기능을 하는 리스너들이 너무 많아서 도대체 뭘 써야 할 지 난감할때가 한두번
이 아니죠...;;

프로젝트 마다 다르나 해외의 글들을 보면 기본은 contoller - serivce - dao 인거 같네요. 문제은 화두는 dao단에
받는 모델이나 도메인 객체가 되갰네요. 그객체가 유연하면 실 시스템도 유연해 질수있으니 예로 객체 맵핑 없는 map이나 List가
되겠죠. 운영도 유연해 집니다. 저같은 경우 3.0이상으로 가면서 serivce - repository 로 바꾸었네요 REST 기반으로
가면서 crud controller를 만들어서 crud repository에 받는 객체는 도메인이 받구요 mapper를 따로 둬서
복잡한것을 service단에 처리하도록 하였습니다.  mapper라면 mybatis고 repository는 spring data
jpa입니다 spring jpa data 쓸만한기능이 좀있네요. 추후 neo4j를 붙여도 되고 클라이언트 집중을 위해
web - service - repository
                        - mapper 로 정했구요
web 단은 wicket으로 정했습니다. wicket은 표준웹또는 웹앱으로 갈때.  web bundle또는 web 자원을 관리가용이
하죵. 보안이라던지. 모바일 등등. 프로제트 오픈 으로 술먹으니 서글퍼 지네요 외국에  나갈까. ㅡㅡ
2012. 2. 14. 오후 6:18에 "강동욱" <happenstant...@gmail.com>님이 작성:

어플리케이션 레이어 구성은 프로젝트마다 특성이 있으니 정답은 없다가 맞을 겁니다

한가지 주의 할 점은 서비스 레이어에 오만가지 로직 코드를 넣으려고 한다는 겁니다. 물론 이도저도 갈 때가 없는 로직, 가령 객체와
객체 사이를 연결하는 로직은 서비스에 있는게 맞습니다.

하지만 도메인 객체가 처리해야 할 로직까지 서비스가 갖고 있다는 것은 분명 문제가 됩니다. 책임 단일화 원칙을 어기게 될것이
뻔해집니다. 이 문제에 빠져든다면 같은 로직의 코드들이 여기저기 널려있게 되겠죠.

서비스 레이어의 예전 이름은 퍼사드 패턴이었습니다. 퍼사드의 사전적인 의미를 생각하다면 서비스는 객체와 객체
사이를 잇는 가교 역할이면 충분합니다. 때문에 서비스 레이어에는 별다른 코드가 존재하지 않는 아주 얇은 층이 되게 됩니다

도메인이 할 일은 도메인이 하도록 하세요. 그럼 코드가 더 명확해집니다.

2012. 2. 14. 오후 9:52 hatto joyce <atha...@gmail.com> 작성:

프로젝트 마다 다르나 해외의 글들을 보면 기본은 contoller - serivce - dao 인거 같네요. 문제은 화두는 dao단에
받는 모델이나 도메인 객체가 되갰네요. 그객체가 유연하면 실 시스템도 유연해 질수있으니 예로 객체 맵핑 없는 map이나 List가
되겠죠. 운영도 유연해 집니다. 저같은 경우 3.0이상으로 가면서 serivce - repository 로 바꾸었네요 REST 기반으로
가면서 crud controller를 만들어서 crud repository에 받는 객체는 도메인이 받구요 mapper를 따로 둬서
복잡한것을 service단에 처리하도록 하였습니다.  mapper라면 mybatis고 repository는 spring data
jpa입니다 spring jpa data 쓸만한기능이 좀있네요. 추후 neo4j를 붙여도 되고 클라이언트 집중을 위해
web - service - repository
                        - mapper 로 정했구요
web 단은 wicket으로 정했습니다. wicket은 표준웹또는 웹앱으로 갈때.  web bundle또는 web 자원을 관리가용이
하죵. 보안이라던지. 모바일 등등. 프로제트 오픈 으로 술먹으니 서글퍼 지네요 외국에  나갈까. ㅡㅡ
2012. 2. 14. 오후 6:18에 "강동욱" <happenstant...@gmail.com>님이 작성:

Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ksug@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+unsubscribe@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

저도 서비스 레이어를 얇게 하고, 도메인을 두껍게 하는 것을 선호합니다.

하지만 이를 잘 하시려면 스프링이 아니라 모델링과 레이어드 아키텍처에 대해서도 잘 알아야 가능합니다.

질문사신 일반적인 웹 구성이라고 하면 스프링과는 무관하게 아키텍처를 어떻게 잡는냐에 대한 문제입니다.

보통은 레이어드 아키텍처를 통해서 구성하지만 요구사항에 따라서 바뀔수도 있습니다.

기술셋에 관해서는 저의 경우 스프링 + 메이븐을 통해서 이러한 레이어드 아키텍처 구조를 잡아갑니다. (참고로 웹프로젝트 1개만 사용하지
않습니다.)

SVN 기준으로 보면 대충 이런 모양이죠.

SVN repository - trunk - 고객엔티티
                                 - 계약엔티티
                                 - 상품엔티티
                                 - ... 기타 단위 업무별 엔티티
                                 - 고객서비스
                                 - 계약서비스
                                 - 상품서비스
                                 - 사이버서비스
                                 - ... 기타 업무별 서비스
                                 - static web 프로젝트 (for 아파치)
                                 - 다이나믹 웹 프로젝트 (for WAS)

여기서 스프링을 끼워넣으면 서비스제공자 역할을 하는(facade) 인터페이스의 생성을 스프링을 통해서 설정하겠죠 ^^

2012년 2월 14일 오후 10:16, 황용대 <sta...@gmail.com>님의 말:

사용하는 샘플  소스 몇개 부칩니다.
package service;

@Controller
@RequestMapping("/menu")
public class MenuService extends CrudController<Menu, Long, MenuRepository>{

        public MenuService() {super(MenuRepository.class);}

        @RequestMapping(method = RequestMethod.GET, params = {"page" , "limit"})
        public @ResponseBody Object findAll(@RequestParam int page,
@RequestParam int limit) {
                return SenchaReturn.ok(repository.findAll(new PageRequest(page - 1, limit)));
        }

package repository;

public interface MenuRepository extends CrudRepository<Menu, Long> {
        Page<Menu> findAll(Pageable pageable);

package domain;

@Entity
@Data
@EqualsAndHashCode(callSuper=false)
public class Menu extends AbstractPersistable<Long> {

     private static final long serialVersionUID = -393252437253310301L;

    @Column(name ="menu_name") private String menuName;
    @Column(name ="parent_id") private int parentId;
    @Column(name ="menu_link") private String menuLink;

    public Menu() {
        this(null);
    }

    public Menu(Long id) {
        this.setId(id);
    }