처음부터 .Net 네임 스페이스 프레임 워크를 만드는 가장 좋은 방법은 무엇입니까?

Question

우리는 VB.Net 2008에서 Classic VB로 응용 프로그램을 마이그레이션하고 있으며 기본 네임 스페이스와 비즈니스 계층을 만들어야합니다. 나의 접근 방법은 우리의 최고 학사를 방문하여 우리 (채권) 회사의 공통 영역을 확인하고 최대한 많은 제네릭 코드로 적절한 상속 모델을 만들려고 노력할 것입니다.

이 작업을 수행 한 모든 사람들의 경험과 질문의 두 번째 부분은 웹 포커스를 OLAP 측면에 통합하는 것입니다. 이것이 기업 네임 스페이스와 파생 상품의 디자인에 어떤 영향을 미칩니 까?

Answer 1

기업용 .NET 프레임 워크를 만드는 가장 좋은 방법은 현재 회사 프로젝트에서 기존 코드를 수확하여 시작하는 것입니다. 구체적이고 구체적인 프로젝트에 대한 코드를 작성하지 않고 BA와 대화함으로써 처음부터 프레임 워크를 구축하면 일부 영역에서 프레임 워크를 설계하는 데 어려움을 겪을 수 있고 다른 부분에서는 일부 필요한 기능을 완전히 잃어 버릴 수 있습니다 (물론 프레임 워크에 인위적인 제약이 가해질 수 있습니다 좋은 이유가없는 고객).

자세한 내용은 Fowler의 Harvested Framework 항목과이 blog post을 참조하십시오.

저는 Web Focus에 익숙하지 않지만 어떤면에서는 영향을 미칠 것이라고 생각합니다. 그러나 Harvested Framework를 사용하면 처음 몇 가지 응용 프로그램에서이 프레임 워크를 사용하면 프레임 워크 내에서 Web Focus를 사용하십시오.

Answer 2

제레미가 프레임 워크에서 올바르게 사용했습니다. 나는 네임 스페이스에 대해 명백한 것을 간단히 언급 할 것이다.

항상 네임 스페이스가 무엇인지 기억하십시오. 네임 스페이스 란 이름이 살아있는 "공간"을 제공하는 것입니다. 특히, 공간 내에 이름을 만드는 사람들이 중복되거나 혼란스러운 이름을 생성 할 가능성이 적은 공간을 제공하기위한 것입니다.

이것은 네임 스페이스가 조직 패턴이나 도메인 지식을 따라 구성된 경우에만 작동합니다. 자주 사용되는 간단한 예는 Company의 패턴입니다. 사업 단위. 신청서. 이론은 주어진 응용 프로그램에서 작업하는 개발자 세트 내에서 이름 중복 가능성이 적습니다. 레이어 나 영역을 기반으로 추가로 분할하려는 대규모 애플리케이션의 경우에는 그렇지 않습니다. 마찬가지로 비즈니스 단위가 너무 큽니다.이를 중단해야합니다.

그러나 모든 경우에 이름을 만드는 두뇌이기 때문에 실제로 두뇌 집합을 분할하려고합니다.

Answer 3

응용 프로그램이 VB6 (VB3이 아님)에있는 경우 먼저 VB6의 클래스 계층 구조로 다시 디자인하는 것이 좋습니다. 그 이유는 모든 변환에서 이전 응용 프로그램의 동작을 유지하려고하기 때문입니다. 이 작업을 수행하고 동시에 재 설계를 수행하는 프로젝트 시간이 늘어납니다.

응용 프로그램의 원래 언어로 디자인을 변경하면 결과적으로 발생하는 버그는 변환이 아닌 디자인으로 인한 것입니다.

나는 지난 20 년 동안 우리 소프트웨어의 세 가지 주요 변환을 수행했습니다. (DOS에서 VB3로) (VB3에서 VB6에서 객체 지향 디자인) 및 (VB6에서 VB.NET으로).

마지막으로 VB.NET에서 쉽게 VB.NET으로 디자인 할 수 있습니다.트릭은 특정 VB6 API 및 인터페이스 (그래픽, 인쇄 등) 뒤에 구성을 숨기는 것입니다>

변환을 수행 할 때 나는 위에서 아래로 작업하는 것이 좋습니다. 먼저 VB6 COM DLL을 호출하는 .NET으로 양식을 변경하십시오. 그런 다음 아래쪽 DLL에 도달 할 때까지 각 계층을 변환하십시오.

다시 디자인을 변경하고 복잡한 응용 프로그램의 다른 언어로 변환하려고하면 변환 시간이 두 배가됩니다.