2008-11-14 4 views
3

home.cs 양식의 내부 코드에 제한이나 성능 저하가 있습니까?코드 줄 수에 대한 C# 패널티?

Visual Studio 2008의 C#에서 데이터베이스 응용 프로그램 프런트 엔드를 작성하고 있습니다. 새로운 양식을 사용하는 대신 최종 사용자에게 표시되는 정보를 변경하는 탭 페이지 방식을 사용하고 있습니다. .

VBA/MS Access에서 오는 코드 줄 수를 초과하면 오류가 발생하고 컴파일되지 않습니다. C#이 Visual Studio 2008에서이 작업을 수행합니까? 그렇지 않으면 성능에 문제가 있습니까? 코드 가독성은 모든 것이 한 곳에서 이루어지기 때문에 문제가 될 수 있지만 일부 상황에서는 이점으로 볼 수 있습니다.

답변

9

성능과 관련하여 걱정해야 할 .cs 파일의 코드 줄은 문제가 될 수 있습니다. 런타임시 양식의 컨트롤 수가 문제가 될 수 있습니다. 몇 가지 탭의 몇 가지 컨트롤 일 경우 문제가 없습니다. 많은 탭의 컨트롤이 수백 개라면 성능 문제가 발생할 수 있습니다 (유용성 문제는 말할 것도 없습니다. 개인적으로 두 개 이상의 탭 행이있는 탭 컨트롤을 싫어합니다).

또한 UI의 목적이 사용자가 연속적으로 모든 탭과 상호 작용하기를 원하는 곳과 같은 마법사 인 경우 탭이 적절하다고 생각하지 않습니다. 탭은 모든 옵션을 한 번에 볼 필요없이 옵션 세트를 사용자에게 표시하기위한 것입니다.

마지막으로 각 탭의 목적이 크게 다르면 기능의 각 비트를 별도의 양식으로 캡슐화하는 것이 더 쉽다는 것을 알게되었습니다. 탭을 사용하면 최소한 각 비트를 사용자 정의 컨트롤로 캡슐화 한 다음 양식의 각 탭에 사용자 정의 컨트롤의 한 인스턴스를 호스팅 할 수 있습니다.

+0

각 탭에 대한 별도의 사용자 컨트롤에 전적으로 동의합니다! 개발과 유지 보수가 훨씬 쉬워 질 것입니다. 나는 원래 포스터가 그것을 채택하기를 바랍니다! –

+0

트릭은 내가 탭을 보여주지 않을 것입니다. 탭 컨트롤을 사용하고 있지만 탭 사이를 이동할 수있는 기능은 숨겨져 있습니다. 왼쪽 아래에는 탭이 변경되는 버튼 메뉴가 있습니다. 나는 상단에 50 개의 탭 메뉴가 있다는 생각이 싫다. 고통스럽고 무서운 것 같습니다. – Matt

1

문제가되지 않습니다.

좋은 코딩 방법을 염두에두고 코드의 가독성과 유지 관리 성을 모듈화하십시오.

반면에 양식에 너무 많은 컨트롤을 추가하면로드하는 데 시간이 오래 걸릴 수 있습니다. 당신이 멋진 인터페이스를 원한다면 디자인에 반영하십시오.

0

끔찍한 소리지만 문제가되는 이유는 없습니다.

+0

나는 동의하지 않지만 그것이 왜 당신에게 끔찍한 지 설명하는 것이 도움이 될 것입니다. 여러 페이지가 모두 하나의 클래스로 구현되는 복잡성으로 인해 끔찍할 것입니다. 별도의 페이지는 별도의 클래스 여야합니다. –

+0

많은 이유가 있으며 모두 주관적입니다. OP가 요구하는 질문이 아니기 때문에이 점을 자세히 설명 할 시점이 없습니다. 그러므로 나는 주관적인 의견을 집중적으로 남겼다. 그것은 그것이 끔찍한 것입니다. – Quibblesome

+0

좋은 화면 이름, Q. :) – MusiGenesis

2

탭을 사용하는 경우에도 탭에있는 콘텐츠를 보유 할 사용자 지정 사용자 정의 컨트롤을 만들 수 있습니다. 탭마다 컨트롤을 만든 다음 다른 탭에 대한 코드를 별도로 유지할 수 있습니다. MSDN here에서 워크 스루 (walk-through)가 있습니다.

위의 귀하의 의견에 따라 탭을 표시하지 않는 것에 대해 저는 어떻게 접근하고 있는지 다시 생각할 것입니다. 필요한 경우 모든 사용자 컨트롤을 Panel에 배치하여 모두 Dock = DockStyle.Fill으로 설정 한 다음 표시 할 속성을 기반으로 표시 및 사용 속성을 변경하는 것이 가장 좋은 이유는 무엇입니까? 자신이 필요로하는 것보다 더 어렵게 만들 수 있습니다.

댓글에 대한 더 많은 답변 - Java의 CardLayout과 같은 것을 찾고있을 수 있습니다. GNU Classpath 버전의 소스는 here이며,이를 구현하는 방법에 대한 아이디어를 줄 것입니다.

+0

안녕하세요. 먼저 말씀 드렸습니다. :) – MusiGenesis

+0

실로 그랬지만 그 가치는 반복되었습니다. –

+0

나는 또한 사용자 컨트롤에 대한 더 많은 정보를 제공하고, 어떻게 해지해야하며, MSDN –

3

내가 예상 할 수있는 유일한 문제는 앞으로는 유지하기가 매우 어려울 것이라는 점입니다.

가능한 한 많이 기본 폼의 로직을 깨뜨려보십시오. 여러분이 무언가를 추가해야 할 때 실제로 적용 할 필요가 없도록 할 수 있습니다.

2

"모든 것이 한 곳에서 이루어지기 때문에 코드 가독성이 문제가 될 수 있지만 일부 상황에서는 장점으로 볼 수 있습니다."

제 경험으로 볼 때이 태도는 미래에 코드를 유지 관리해야하는 사람을 궁극적으로 두려워하게 만듭니다. 코드를 모듈화하여 코드가 변경 될 수있는 조각이나 명확하게 제공되는 조각 다른 목적은 서로 떨어져 있습니다.

VS에서 파일 길이에 제한이 있다고 생각하지 않지만 파일이 길어짐에 따라 심각하게 좌절하는 성능 저하가 발생할 것이라고 생각합니다. 특히 디자인을 전환하는 동안 코드보기.

나는 미래의 자아와 그/그녀의 온전함을 저장하고 코드를 논리적으로 분리 된 파일로 나눌 것을 촉구합니다. 나중에 고마워 할거야!

0

나는 30,000 라인이 넘는 나의 새로운 직업으로 물려받은 양식을 가지고 있습니다. 그것은 완전히 암입니다. 코딩하고 모듈화하기 전에 생각하십시오!

+2

이것은 OP의 질문에 "한계 또는 성능 저하가 있습니까?"라고 말하지 않기 때문에 대답보다 더 좋은 설명이됩니다. –