이 주제에 대해 잠시 동안 검색했지만 지금까지 "만족스러운"대답을 찾지 못했습니다.웹 응용 프로그램에서 마법사를 올바르게 처리하기위한 패턴/아키텍처
나는 설명하려고 노력할 것이다.
우리는 일부 엔티티의 경우 생성/편집 프로세스에서 마법사를 필요로하는 웹 응용 프로그램을 개발 중이므로 사용자는 단계를 전환하고 이러한 엔티티를 작성하는 데 필요한 복잡성과 흐름을보다 잘 제어 할 수 있습니다.
모든 대안은 마법사의 엔티티에 대한 변경을 요구하는 것으로 끝나는 wicked wizard gem과 ASCII muti-step 양식에 대한 캐스트를 확인했습니다. IMO, 마법사는 엔티티와 인터페이스와는 아무런 관련이없는 뷰일뿐입니다. 뷰의 문제를 처리하기 위해 모델을 변경하면 결국 SRP (Single responsibility principle)를 위반하게됩니다. 관심사 분리 자체. 세션에 데이터를 저장하는 것은 옵션이지만 이미 존재하는 (영구적 인) 엔티티를 편집 할 때는 세션에서 변경 사항을 유지하는 대신 각 단계에서 유지해야합니다 ...
So , 너희 중 누구라도 이미 마법사로 앱을 만들었 니? 어떤 제안?!?
추신 : 저는 레일즈를 사용하고 있습니다.하지만 기술에 관계없이 설명 된 시나리오를 올바르게 모델화하는 방법에 대한 질문이 있습니다.
내가 제안한 것과 매우 유사한 접근법을 사용하여 끝 냈습니다. 모든 생성 단계는 AngularJs보기, 컨트롤러 및 일반 JS 모델을 통해 클라이언트 측에서 처리됩니다. 필요한 데이터는 일반 XHR 요청을 통해 서버에서 빌드되고 검색되며 클라이언트 측 단계 모델에 기존 모델을 매핑하기 위해 서버 측에서 일부 맵퍼를 구현했습니다. –
그레이트! 도움이되었습니다. AngularJS와 함께했던 특별한 점은 무엇입니까? – ATechieThought
전혀 아닙니다 ... 앱을 통해 이미 사용 되었기 때문입니다. –