aspx 페이지의 인라인 코드가 좋은 습관인가요?
https://stackoverflow.com/questions/68509
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
다음 코드를 사용하면 뒤에 있는 코드의 변수를 마우스 오른쪽 버튼으로 클릭하고 리팩터링(이 경우 이름 바꾸기)하는 기능을 잃게 됩니다.
<a href='<%# "/Admin/Content/EditResource.aspx?ResourceId=" + Eval("Id").ToString() %>'>Edit</a>
이 방법은 어디에서나 볼 수 있지만 속성 이름을 변경해도 더 이상 컴파일 시간 오류가 발생하지 않으므로 이상해 보입니다.내가 선호하는 접근 방식은 다음과 같은 작업을 수행하는 것입니다.
<a runat="server" id="MyLink">Edit</a>
그런 다음 뒤에 있는 코드에서
MyLink.Href= "/Admin/Content/EditResource.aspx?ResourceId=" + myObject.Id;
인기 있는 코딩 사이트와 블로그(예:Scott Guthrie) 코드는 작지만 저는 ASP.NET을 사용하는 경향이 있습니다. 왜냐하면 ASP.NET은 컴파일되고 런타임이 아닌 컴파일 타임에 문제가 있는지 확인하는 것을 선호하기 때문입니다.
해결책
나는 이것을 나쁜 습관이라고 부르지는 않겠습니다(어떤 사람들은 동의하지 않을 것입니다. 하지만 왜 그들이 우리에게 처음에 그런 옵션을 주었나요?). 하지만 이 관행을 따르지 않으면 전반적인 가독성과 유지 관리성이 향상될 것이라고 말하고 싶습니다.이미 좋은 지적을 하셨습니다. 이는 IDE 기능 제한(예: 디자인 시간 검사, 컴파일 시간 경고 등)입니다.
얼마나 많은 원칙을 위반하는지(코드 재사용, 문제 분리 등)에 대해 계속해서 설명할 수 있지만 거의 모든 원칙을 위반했지만 몇 년이 지난 후에도 여전히 작동하는 많은 애플리케이션이 있다고 생각할 수 있습니다.나는 코드를 가능한 한 모듈화하고 유지 관리 가능하게 만드는 것을 선호합니다.
다른 팁
이는 스파게티 코드로 알려져 있으며 많은 프로그래머가 이를 불쾌하게 생각합니다.다시 한 번 말씀드리지만, 귀하와 귀하 회사의 다른 개발자가 해당 내용을 읽을 수 있고 유지 관리할 수 있다고 생각한다면 제가 무엇을 해야 할지 알려드릴 수 있을까요?
하지만 중복을 줄이기 위해 포함을 사용하십시오(DRY - 반복하지 마십시오).
나는 가끔씩만 사용하며, 일반적으로 특별한 이유로 사용합니다.나는 코드를 HTML 마크업과 완전히 분리함으로써 항상 더 행복한 개발자가 될 것입니다.다소 개인적인 취향이지만 이것이 더 나은 방법이라고 말하고 싶습니다.
그것은 당신에게 달려 있습니다.때로는 간단한 작업을 위해 전체 템플릿 시스템을 구축/사용하는 것보다 "spagehetti" 코드를 유지 관리하는 것이 더 쉽지만 일단 상당히 복잡한 페이지를 얻거나 더 구체적으로 페이지 자체에 많은 논리를 포함하기 시작하면 다음과 같은 문제가 발생할 수 있습니다. 정말 빨리 더러워져요.
나는 asp.net이 aspx 페이지에 코드를 요구한다는 것이 흥미롭다고 생각합니다.3.5의 목록 보기 및 심지어 ASP.NET MVC.MVC에는 기본적으로 뒤에 코드가 없지만 정보를 렌더링하기 위해 페이지에 코드가 있습니다.
템플릿 개발 측면에서 생각한다면 코드 뒤가 아닌 뷰에 유지하는 것이 현명합니다.클릭을 처리하기 위해 눈에 띄지 않는 JS를 사용하여 앵커에서 목록 항목으로 변경해야 하는 경우에는 어떻게 됩니까?예, 이것은 가장 좋은 예가 아니라 단지 그것과 예입니다.
나는 항상 나에게 디자이너(HTML, CSS 등)가 있다면 그에게 무엇을 하게 할 것인지, 코드 뒤에 있는 코드에서 무엇을 할 것인지, 그리고 우리가 어떻게 서로의 발가락을 밟지 않을 것인지에 관해 생각하려고 노력합니다.
잘 캡슐화할 수 없다면 그것은 나쁜 습관일 뿐입니다.
다른 모든 것과 마찬가지로 지저분하고 읽을 수 없는 스파게티 코드를 만들 수 있습니다. 단, 콘텐츠에 태그가 있다는 점만 제외하면 설계상 세상에서 가장 읽기 쉬운 코드는 아닙니다.
나는 템플릿에서 많은 if를 유지하려고 노력하지만 과도한 캡슐화로 인해 div x가 클라이언트에 실행되지 않는 이유를 확인하기 위해 13개의 다른 위치를 조사해야 하므로 절충안이 됩니다.
그렇지는 않지만 때로는 필요악이기도 합니다.
예를 들어, 코드 숨김이 우려 사항을 더 잘 분리하는 것처럼 보이지만 문제는 원하는 만큼 명확하게 우려 사항을 분리하지 못할 수 있다는 것입니다.일반적으로 우리가 작업 뒤에 코드를 작성할 때 MVC 프레임워크에서 앱을 구축하지 않습니다.코드 뒤의 코드는 적어도 MVC와 비교할 때 어쨌든 유지 관리 및 테스트가 쉽지 않습니다.
ASP.NET MVC 앱을 구축하는 경우 분명히 인라인 코드에 갇혀 있다고 생각합니다.그러나 MVC 패턴으로 구축하는 것은 유지 관리성과 테스트 가능성 측면에서 가장 좋은 방법입니다.
요약하기:인라인 코드는 좋은 습관은 아니지만 필요악입니다.
내 2센트.
보통은 이렇게 사용합니다.
<a href='<%# DataBinder.Eval(Container.DataItem,"Id",""/Admin/Content/EditResource.aspx?ResourceId={0}") %'>
