2008-09-22 4 views

답변

2
  • 마스터 페이지 유형 콘텐츠의 일부가 아닌 둘 이상의 페이지에 표시 될 웹 사용자 컨트롤을 만듭니다. 예 : 응용 프로그램에 10 페이지의 제품 정보가 표시되는 경우 표시 코드를 10 번 잘라내 지 않고 10 페이지에 사용되는 사용자 정의 컨트롤을 갖는 것이 가장 좋습니다.
  • 가능한 한 코드 뒤에 비즈니스 로직을 넣지 마십시오. 코드 숨김은 페이지에 물건을 배치하고 비즈니스 계층에서 데이터를주고받는 것과 직접 관련이없는 작업을 수행하기 위해 비즈니스 계층으로 연기해야합니다.
  • 바퀴를 재발 명하지 마십시오. 내가 보아 왔던 엉성한 코드 숨김은 프레임 워크가 이미 제공하고있는 일을하는 코드로 구성되어있다.
  • 일반적으로 HTML에서 스크립트 블록을 사용하지 마십시오.
  • 한 페이지에 너무 많은 일을하지 마십시오. 내가 시간과 시간을 다시 보았던 것은 모드를 추가하고 편집했다고 말하는 페이지입니다. 괜찮아. 그러나 추가하고 편집 할 많은 하위 모드가있는 경우 사용자 컨트롤을 통해 재사용하면서 각 하위 모드에 대해 여러 페이지를 사용하는 것이 좋습니다. 당신은 정말로 당신의 사용자가 무엇을하려고 하는지를 결정하기 위해 중첩 된 IF의 무리를 피하고 그에 따라 올바른 것을 보여주는 것을 피할 필요가 있습니다. 페이지에 가능한 여러 상태가있는 경우 상황이 빠르게 벗어나게됩니다.
  • 페이지 수명주기를 배우고 익숙하게 활용하십시오. 코더가 페이지 수명주기를 더 잘 이해한다면 필자가 보았던 추악한 코드 숨김 페이지가 더 깨끗해질 수 있습니다.
+0

모든 것이 첫 번째 점을 제외하고, 좋은; 마스터 페이지를 사용하면 공유 된 프레젠테이션을위한 사용자 정의 컨트롤의 필요성이 완전히 무효화됩니다. 여러 페이지간에 공유되는 내용은 모두 마스터 페이지에 있어야합니다. – Dexter

+1

아마도 충분히 명확하지 않지만 비즈니스 개체를 표시하고 편집하는 것과 같은 반복적 인 작업을 위해 컨트롤을 사용하는 것이 좋습니다. 예 : 제품을 볼 수있는 10 페이지가 있다고 가정 해보십시오. 10 페이지에 cut'n'pasted HTML보다 하나의 사용자 컨트롤을 갖는 것이 가장 좋습니다. 설명을 위해 답변이 업데이트되었습니다. –

1

# 1 날 마스터 페이지에서 시작합니다. 다시 장착 할 때의 고통입니다.

3

나는 일반적으로 명확 유지하려고 ...하지만 난 웹폼을 사용 할 때, 나는이 교훈을 따르 깨끗한 결과 HTML을 유지

  1. 을 : 당신이 손 아니에요해서 -coding every <div>은 생성 된 코드가 읽을 수없는 악몽이되어야한다는 것을 의미하지 않습니다. 추악한 코드를 생성하는 컨트롤을 피하면 나중에 디버그 시간을 줄이고 문제를 쉽게 볼 수 있습니다.
  2. 외부 의존성 최소화 : 다른 사람의 코드를 디버깅하기 위해 돈을 지불하지 않았습니다. 을 수행하는 경우 타사 구성 요소를 사용하도록 선택한 다음 소스를 가져 와서 버그를 수정하는 데 비정상적으로 많은 시간을 낭비하지 않아도됩니다.
  3. 한 페이지에서 너무 많이하는 것을 피하십시오. : 주어진 페이지에 대해 복잡한 "모드"를 구현하는 경우 마스터 페이지를 사용하여 일반적인 측면을 제외하고 여러 개의 단일 모드 페이지로 분할하는 것을 고려하십시오.
  4. 포스트 백을 피하십시오. : 이것은 항상 끔찍한 생각이었고, 덜 끔찍하지 않았습니다. 포스트 백에 의존하는 컨트롤을 사용하지 않아도 저장하는 두통은 좋은 보너스입니다.
  5. 피할 것 VIEWSTATE : # 4에 대한 의견보기.
+0

어떻게 webform으로 포스트 백을 피할 수 있습니까? 포스트 백은 webforms 모델의 핵심입니다. 코드 뒤에있는 코드가 페이지로드에 있다는 것을 의미합니까? –

+0

예. 그것이 바로 그것이 의미하는 것입니다. 최종적으로 페이지를 만드는 것에 직접적으로 관심이없는 것은 어딘가의 고유 한 목적 별 클래스에 있기 때문에 매우 적은 코드 숨김 * 기간 *이있는 페이지입니다. 그건 ... 아주 자유 롭습니다. – Shog9

+0

나는 그 사용 예를보고 싶다. 이론적으로는 좋지만, 본질적으로 유효성 검증과 같은 서버 측에서 수행해야 할 것들이있다. – Dexter

-1

버전 컨트롤과 폴더 구조를 사용하면 너무 많은 파일이 모두 같은 폴더에 들어 가지 않도록 할 수 있습니다.폴더에 1,000 개 이상의 파일이 있고 폴더를 열 때 폴더를 모두로드해야하기 때문에 Windows 탐색기에서 무언가를로드하기를 기다리는 것보다 더 고통스럽지 않습니다. 변수와 메소드를 명명하는 관습은 가능한 한 선행을하는 것이 좋습니다. 이렇게하면 다른 개발자가 모두 고유 한 방식으로 접촉하고 고통스럽게 보여주는이 코드가 없습니다.

디자인 패턴을 사용하면 코드를 구성하고 크기를 적절하게 조정하는 데 도움이 될 수 있습니다. 전략 패턴은 지원되어야하는 새로운 유형의 제품이나 장치를 추가해야 할 때 더 쉬운 시간을 가져올 수 있습니다. 일부 어댑터 또는 외관 패턴을 사용하는 경우와 유사합니다.

마지막으로 IE 사용자를위한 것일뿐 아니라 IE, Firefox 또는 Safari에서 양식을 쉽게로드하고 모양이 좋아야하는지 양식을 유지할 것인지 결정하십시오.

3

큰 프로젝트를 통해 내가 줄 수있는 가장 좋은 제안은 모든 개발자가 잘 훈련 받고 잘 알고있는 공통 디자인 패턴을 따르는 것입니다. ASP.NET을 다루는 경우 가장 좋은 두 가지 옵션은 다음과 같습니다.

o 모델 뷰 발표자 (though this is now Supervisor Controller and Passive View). 이것은 모든 개발자가 큰 어려움없이 따라갈 수있는 사용자 인터페이스와 비즈니스 모델 간의 분리를 추진하는 견고한 모델입니다. 결과 코드는 훨씬 더 테스트 가능하고 유지 보수가 가능합니다. 문제는 강제되지 않으며 모델을 구현하기 위해 많은 지원 코드를 작성해야한다는 것입니다.

o ASP.NET MVC 이 문제는 미리보기에 문제가 있음을 나타냅니다. 나는 Tatham Oddie와 이야기를 나눴고 매우 안정적이고 사용 가능하다고 언급 될 것입니다. 나는 그것을 좋아한다, 그것은 개발자의 최소한의 추가 코드로 염려의 분리를 강요한다.

내가 선택한 모델은 모델을 갖고 모든 개발자가 해당 모델을 고수 할 수 있도록하는 것이 가장 중요하다고 생각합니다.

0

오드 (Odd)가 말한 바에 따르면, 저는 지금까지 저에게 잘 작동하는 MVP (Model Presentation)라는 모델을 시험 중입니다. 나는 아직도 그것을 이해하고 그것을 나의 자신의 사용에 적응시키고있다. 그러나 그것은 내가 쓰곤했던 코드로부터 상쾌하다.

여기를 체크 아웃 : Presentation Model

관련 문제