프로젝트를 어떻게 구성합니까? [닫은]

특정 스타일의 프로젝트 구성이 있습니까?

예를 들어, 현재 볼리비아에있는 몇 곳의 학교를위한 프로젝트를 만들고 있습니다.

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

프로젝트를 정확히 어떻게 구성합니까? 당신이 조직하고 자랑스럽게 여기는 예가 있습니까? 솔루션 창의 스크린 샷을 공유 할 수 있습니까?

내 응용 프로그램의 UI 영역에서 다른 형식과 형식을 구성하기 위해 좋은 스키마를 결정하는 데 문제가 있습니다.

편집하다:

.UI 프로젝트에서 다른 양식을 구성하는 것은 어떻습니까? 다른 양식을 어디에 / 어떻게 그룹화해야합니까? 프로젝트의 루트 수준에 모두 배치하는 것은 나쁜 생각입니다.

프로젝트를 설계하고 아키텍처를 배치 할 때 두 가지 방향에서 시작합니다. 먼저 설계중인 프로젝트를보고 어떤 비즈니스 문제를 해결해야하는지 결정합니다. 나는 그것을 사용할 사람들을보고 조잡한 UI 디자인으로 시작합니다. 이 시점에서 나는 데이터를 무시하고 사용자가 무엇을 요구하고 누가 사용할 것인지 살펴보고 있습니다.

일단 그들이 무엇을 요구하는지에 대한 기본적인 이해를 마치면 핵심 데이터가 무엇인지를 결정하고 그 데이터에 대한 기본 데이터베이스 레이아웃을 시작합니다. 그런 다음 데이터를 둘러싼 비즈니스 규칙을 정의하기 위해 질문을 시작합니다.

양 끝에서 독립적으로 시작함으로써 양 끝을 하나로 통합하는 방식으로 프로젝트를 배치 할 수 있습니다. 나는 항상 디자인을 서로 융합하기 전에 가능한 한 오랫동안 분리되도록 노력하지만 앞으로 나아갈 때마다 각각의 요구 사항을 명심하십시오.

일단 문제의 각 끝을 잘 이해하면 문제를 해결하기 위해 만들어 질 프로젝트의 구조를 세우기 시작합니다.

프로젝트 솔루션의 기본 레이아웃이 만들어지면 프로젝트의 기능을 살펴보고 수행되는 작업 유형에 따라 사용되는 기본 네임 스페이스 집합을 설정합니다. 계정, 쇼핑 카트, 설문 조사 등이 될 수 있습니다.

다음은 항상 시작하는 기본 솔루션 레이아웃입니다. 프로젝트가 더 잘 정의됨에 따라 각 프로젝트의 특정 요구를 충족하도록 수정합니다. 일부 영역은 다른 영역과 병합 될 수 있으며 필요에 따라 몇 가지 특수 영역을 추가 할 수 있습니다.

솔루션 이름

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.

프로젝트를 레이어로 나누는 것을 좋아합니다

이렇게하면 순환 종속성을보다 쉽게 ​​관리 할 수 ​​있습니다. 예를 들어 실수로 View 프로젝트 (계층)를 가져 오는 프로젝트가 없음을 보장 할 수 있습니다. 또한 하위 레이어에서 레이어를 나누는 경향이 있습니다. 따라서 모든 솔루션에는 다음과 같은 프로젝트 목록이 있습니다.

• 제품 코어
• 제품. 모델
• 제품 발표자
• 제품 지속성
• Product.UI
• 제품 검증
• 제품 보고서
• Product.Web

그들은 내 응용 프로그램의 더 큰 "빌딩 블록"입니다. 그런 다음 각 프로젝트 내에서 네임 스페이스를보다 논리적으로 구성하지만 많이 다릅니다. 많은 양식을 만들 때 UI의 경우 공간 분할을 생각한 다음 각 "공간"에 대한 네임 스페이스를 만듭니다. 많은 사용자 환경 설정 사용자 정의 컨트롤 및 양식이 있다고 가정 해 보겠습니다. 사용자 환경 설정이라는 네임 스페이스가 있습니다.

프로젝트 조직

나는 일반적으로 내 프로젝트를 네임 스페이스로 나눕니다. 응용 프로그램 또는 구성 요소의 각 계층은 자체 프로젝트입니다. 솔루션을 프로젝트로 나누는 방법을 결정하는 데 있어 해당 프로젝트의 재사용 성과 종속성 에 중점을 둡니다 . 팀의 다른 구성원이 프로젝트를 사용하는 방법에 대해 생각하며, 다른 프로젝트를 진행하는 경우 시스템의 일부 구성 요소를 사용하면 도움이 될 수 있습니다.

예를 들어, 전체 프레임 워크 세트 (이메일, 로깅 등)가있는이 프로젝트 만 있으면 충분합니다.

MyCompany.Frameworks

다른 경우에는 프레임 워크를 여러 조각으로 나누어 개별적으로 가져올 수 있습니다.

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

양식 구성

UI 프로젝트에서 양식을 구성하면 프로젝트가 확장됨에 따라 실제로 모핑됩니다.

• 작음 - 아주 작은 프로젝트 에는 간단한 양식 폴더로 충분할 수 있습니다. 때로는 네임 스페이스처럼 구조를 오버 엔지니어링하여 필요한 것보다 복잡하게 만들 수 있습니다.

• 중대형 -여기서는 보통 양식을 기능 영역으로 나누기 시작합니다. 내 응용 프로그램의 일부에 사용자를 관리하기위한 3 개의 양식이 있고 축구 게임 및 점수를 추적하는 일부가있는 경우 양식> 사용자 영역 및 양식> 게임 영역 또는 이와 유사한 것이 있습니다. 그것은 실제로 프로젝트의 나머지 부분, 내가 세분화 한 정도에 대해 얼마나 많은 양식을 가지고 있는지에 달려 있습니다.

하루가 끝날 때 네임 스페이스와 폴더는 바로 구성하고 찾을 수 있도록 도와줍니다.

실제로, 그것은 팀, 프로젝트 및 더 쉬운 것에 달려 있습니다. 일반적으로 시스템의 각 레이어 / 구성 요소에 대해 별도의 프로젝트를 만드는 것이 좋지만 항상 예외가 있습니다.

시스템 아키텍처에 대한 지침은 Microsoft의 Patterns and Practices 사이트를 참조하십시오 .

.NET에서 코드를 작성할 때 관련 기능의 클러스터가있는 경향이 분명합니다. 각각은 동일한 하위 집합을 가질 수 있습니다. 나는 주요 프로젝트를 물리적으로 나누고 싶습니다 .VS 프로젝트 당 하나입니다. 그런 다음 어셈블리를 사용하여 논리적으로 세분화합니다. 이 패턴에 따라 현재 프로젝트 중 하나는 다음과 같습니다.

• Wadmt (솔루션)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt. 서비스
  • Wadmt. 테스트
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

잘하면 그것은 당신에게 유용합니다. 분리 수준을 알아내는 데 시간이 걸렸습니다.

솔루션 구성 계획을 세우는 것이 좋으며 여러 가지 방법이 있습니다. 여러 프로젝트에서 공유되는 일부 기능이 있으며 사용자에게 일관성을 제공합니다. 프로젝트 조직은 우리가하는 일에 달려 있습니다. 핵심은 다음과 같습니다.

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

거기에서 그것은 실제로 설정에 달려 있습니다. 클라이언트 응용 프로그램과 웹 프런트 엔드 (교실 또는 기타 연구에서 사용 결과를 수집하는 데 유용한)가 모두있는 경우 공통으로 공유되는 코드 (예 : 직렬화 될 데이터 개체)가있는 프로젝트가 필요합니다.

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

필요에 따라 다른 하위 프로젝트를 추가 할 수도 있습니다. 내가 말했듯이, 그것은 실제로 프로젝트에 달려 있습니다. 일부 프로젝트는 정말 간단하며 핵심 요소 만 필요합니다. 우리는 임의의 프로젝트 분리와 싸우려고 노력하므로 레이어로 나누는 것이 실제로 의미가 있습니다. 계층은 프로젝트, 솔루션간에 공유해야하는 대상 또는 플러그인 / 확장해야하는 대상으로 정의됩니다.

많은 사람들이 여기서 DRY를 고려하지 않는 것이 흥미 롭습니다. 내 인생에서 개발자가 그 때문에 빌드 할 수없는 디렉토리 구조를 만든 것은 몇 번 일어났습니다. 프로젝트 이름을 솔루션 및 프로젝트 디렉토리에서 제외하십시오!

여기 내 방법이 있습니다.

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

응용 프로그램을 디자인 할 때 항상 응용 프로그램 간에 종속성 이있는 모듈 로 간주 됩니다. 디자인을 염두에두면 상향식 전략을 사용하여 디자인 을 개발합니다. 각 모듈을 개발 한 다음 함께 작동시킵니다.

글쎄, 그 모듈 은 내 솔루션 (일반적으로 클래스 라이브러리 )의 프로젝트 입니다. 각 모듈에는 서로 다른 네임 스페이스 와 자체 디자인 ( 클래스 포함 등)이 있습니다.

그 중 하나의 모듈 은 IS GUI ( 그래픽 사용자 인터페이스 ).

또한 항상 수정 제어 도구를 사용하여 각 프로젝트의 변경 사항을 추적합니다. 나는 Git을 제안한다 . 오픈 소스이며 배포되어 있으며 무료로 사용할 수 있습니다.

새 프로젝트를 시작할 때마다해야 할 일에 대한 광범위한 사양을 얻습니다. 이러한 의견을 수렴하면 컨텍스트를 제공함으로써 도움이되므로 프로젝트 목표를 달성하기위한 최선의 (또는 가장 적합한) 방법을 생각합니다. 이 시점에서 의도 한 솔루션을 제공 할 수있는 desgin 패턴에 대해 생각하기 시작합니다. 프로젝트에 채택 할 디자인 패턴을 고려하여 프로젝트 구성을 시작합니다.

몇 가지 예 :

1. 프로젝트가 입력 데이터 화면을 만드는 것에 만 의존하는 경우. 아마도 MVC 패턴을 사용했을 것입니다.
2. 대부분의 플랫폼을 지원하는 강력한 UI로 프로젝트를 사용하려는 경우 MVVM desgin 패턴이 도움이됩니다.

이 각각은 특정 방식으로 프로젝트를 구성해야한다는 것을 명심하십시오.

다음은 몇 가지 참고 사항입니다.

.Net 디자인 패턴 .

디자인 패턴 .

객체 지향 디자인 .

도움이 되었기를 바랍니다.