프리젠 테이션과의 로직 분리 : HTTP 변수 이름?

Question

이것은 아마도 실제 세계가 아닌 학술적 질문으로 간주 될 수 있습니다. 그러나 누군가 훌륭한 아이디어를 갖고 있는지 알아보기 위해 그것을 던지십시오! 우리는 애플리케이션의 비즈니스 로직을 프리젠 테이션과 분리하여 유지하는 것이 좋은 아이디어라는 것을 알고 있습니다. (저는 웹 애플리케이션 atm을보고 있습니다), 비즈니스 로직과 HTTP 변수가 무엇인지를 이해해야합니다. 그 다음에 프로세스)와 프리젠 테이션 레이어에 의해 보내지는 변수 명.

이것은 템플릿에 어떤 변수 이름을 사용할 지 디자이너에게 알려주는 간단한 문제입니까? 템플릿은 변수 이름이 무엇인지 (JS/CSS 선택자에 사용하지 않는 한) 알 필요가 없으므로 왜 그 변수가 '하드 코드 된'것이되어야합니까? 비즈니스 로직이 이름을 변수에 넣어서 인쇄해야합니까? 템플릿의 복잡성의 또 다른 계층은 무엇입니까?

누구든지이 경험이 있거나 그것을 처리하는 방법에 대한 생각이 있습니까?

감사합니다, 앨런

Answer 1

내 생각은 ... 나는 그것이 개발자에 따라 달라집니다 것 같아요. 앱을 만들 때마다 내가 제안한대로 비즈니스와 뷰 로직을 분리하고 보통 ViewModel을 정의합니다. 그런 다음 viewModel은 비즈니스 로직과 뷰 간의 계약이됩니다. 이것은 양 팀 (UI 및 비즈니스 로직 개발자)이 독립적으로 개발할 수있게 해주 며 물론 테스트가 용이합니다.

로직 분리보기에는 다양한 접근 방식이 있습니다 만, 경험을 통해 계약을 정의 할 수 있다면 두 가지 (어떤 패턴을 사용하든간에 어떤 패턴을 사용 하느냐에 따라 다름) 개발이 쉬워집니다. 특히 개별 구성 요소를 만드는 별도의 팀이있는 경우 더욱 그렇습니다.

Answer 2

이전에 웹 개발에서 일했었을 때 (현재 저는 관리자/지원에 있습니다) 문제는 디자이너가 나중에 대체 될 자리 표시자를 사용한다는 아이디어에 착수하지 못했다는 것입니다. 일부 복잡한 레이아웃 (예 : 동적 아코디언 유형의 계층 적 탐색 메뉴)은 애니메이션 및 기능 대 폰트 및 색상 제어를 처리하는 스타일 시트 부분을 디자인하는 데있어 닭고기 및 계란 문제가있었습니다.

디자이너 중 가장 능력이있는 사람도 도구를 사용해도 문제를 해결할 수는 없습니다.

우리가 취한 접근법은 개발자가 HTML 조각의 예를 제공하여 디자이너가 페이지를 작성한 다음 개발자가 조각을 동적으로 생성 된 내용으로 대체하고 스타일 시트를 정리하고, 모든 클래스를 병합합니다.

우리가 도달 할 수있는 가장 실용적인 해결책이었습니다.

C.