Download tài liệu này tại đậy.
Chương 3 - Kết cấu các Project và
Solution trong Source Control
Objectives
- Kết cấu các project và solution của Microsoft®
Visual Studio® Team System một cách phù hợp.
- Biết được khi nào sử dụng multiple solution
và khi nào sử dụng một single solution.
- Xác định những cấu trúc thích hợp cho những đội
nhỏ, vừa và lớn(small, medium-size and very large teams).
Overview
Chương này
giải thích các tùy chọn khác nhau cho cấu trúc những tập tin project và
solution của Visual Studio trong một sự quản lý thích hợp đối với nhóm phát triển.
Visual Studio sử dụng những file solution (.sln) để nhóm các file dự án Visual
Studio (.csproj and .vbproj) lại với nhau. Quyết định để kết cấu những project
và solution như thế nào là một quyết định quan trọng vì các pattern(mô hình) mà
bạn chọn có một số các hiệu ứng phụ. Thí dụ, các thành viên của những nhóm phát
triển tác động dễ dàng đến việc kéo và đẫy(push and pull) các solution và
project đến và từ source control, cơ chế mà bạn sử dụng để tham chiếu(reference)
các dependency và cũng như là các processes.
Nếu bạn đang
làm việc trên một dự án nhỏ bạn có thể sử dụng một single solution để chứa tất
cả các file project của bạn. Nếu bạn đang làm việc trên một dự án phát triển phần
mềm với một số lượng lớn các file project , bạn nên sử dụng những file multiple
solution để nhóm các project có liên quan mà tương ứng với nhóm các chức năng của
bạn trong tổng thể dự án nhóm. Tùy thuộc vào kịch bản cụ thể bạn có thể cũng cần
một tập tin single solution để nhóm tất cả các file project lại với nhau.
Sử dụng chương này như thế nào
Sử dụng chương
này để chọn một phương pháp tiếp cận cho việc kết cấu Visual Studio solution và
project của bạn. Để đạt được lợi ích tốt
nhất từ chương này, bạn nên:
- Use
the strategies list(Sử dụng danh
sách các chiến thuật). Sử dụng danh
sách các chiến lược khởi đầu như: single solution, partitioned solution, và multiple
solutions để nhanh chóng đánh giá phương pháp tiếp cận tốt nhất cho kịch bản của
bạn.
- Đọc những
phần kịch bản mà có liên quan nhiều nhất đến nhu cầu của bạn. Đọc phần mô tả
làm thế nào để triển khai các tùy chọn mà chọn đã chọn.
- Đọc
chương 4, "Structuring Projects and Solutions in Team Foundation Server Source
Control" kế tiếp. Chương 4 giới thiệu
cho bạn những cân nhắc quan trọng nên nhớ khi lưu trữ code trong Team
Foundation Server (TFS) source control.
- Đọc
chương 6, "Managing Source Control Dependencies in Visual Studio Team System".
Kết cấu project tác động đến các chiến
lược có sẵn cho bạn khi quản lý những thành phần phụ thuộc qua các project và solution. Để biết thêm thông
tin về bằng cách nào để quản lý các phụ thuộc, hãy đọc chương 6.
• Đọc các chủ đề How To kèm theo. Đọc các chủ đề How To (Làm như thế
nào để ) và đi theo từng bước các thao tác khác nhau được thảo luận trong
chương này:
-
How To: Kết cấu ASP.NET
Applications trong Visual Studio Team Foundation Server.
-
How To: Kết cấu Windows
Applications trong Visual Studio Team Foundation Server.
-
How To: Kết cấu những thư mục Source Control của bạn trong Visual Studio Team Foundation Server.
Những chiến lược cho cấu trúc
Solution và Project
Ba chiến lược
chung nhất được sử dụng cho việc kết cấu các file solution và project là:
- Single
solution. Nếu bạn làm việc trên một hệ thống nhỏ, hãy tạo một single
solution và đặt tất cả các file dự án của bạn trên đó.
- Partitioned
solution. Nếu bạn làm việc trên một hệ thống lớn, sử dụng những multiple
solution để nhóm các project liên quan lại với nhau. Tạo các solution để nhóm một
cách hợp lý các nhóm nhỏ project mà một nhà phát triển hầu như muốn chỉnh sửa
như là một tập hợp, và sau đó tạo một master Solution (solution chủ) để chứa tất
cả các dự án của bạn.Phương pháp tiếp cận này làm giảm bớt số lượng data cần được lấy từ
source control khi bạn chỉ cần làm việc
trên những project cụ thể.
-
Multiple solutions. Nếu bạn đang làm việc trên một hệ thống rất lớn mà yêu cầu hàng chục project hay nhiều hơn , hãy sử dụng multiple
solution để làm việc trên các sub-systems(hệ thống con) nhưng đối với dependency
mapping và performance reasons không tạo một master solution mà chứa tất cả các
project.
Nói chung, bạn nên:
- Sử dụng chiến lược một single solution nếu kết
quả solution không quá lớn để load vào Visual Studio.
- Sử dụng multiple solutions để tạo những specific
views trên các sub-systems của ứng dụng của bạn.
- Sử dụng multiple solutions để giảm thời gian
load một solution và giảm thời gian build cho các nhà lập trình.
Hãy nhớ những
điều sau khi thiết kế một cấu trúc project và solution:
- Mỗi project đều tạo ra một assembly tại thời
gian build. Bắt đầu bởi việc xác định assembly nào bạn muốn tạo và sau đó sử dụng
nó để quyết định những project nào bạn cần. Sử dụng nó để quyết định phần code
cơ bản nào của bạn được xem như là nhân tố trong các project.
- Bắt đầu với cấu trúc single solution đơn giản
nhất. Chỉ thêm các phần phức tạp vào kết cấu của bạn khi nó thật sự cần thiết.
- Khi thiết kế một kết cấu multi-solution:
- Xem xét tính độc lập của dự án. Hãy thử nhóm các project
có phụ thuộc vào nhau như là những phần của cùng một solution. Điều này
cho phép bạn sử dụng các tham chiếu project trong phạm vi solution của bạn. Bằng cách sử dụng
các project references thay vì file references, cho phép Visual Studio để xây
dựng cấu hình (debug/release) được đồng bộ hoá , và để theo dõi các version để
xác định xem khi nào thì các project cần được built lại. Cố gắng giảm thiểu số
lượng các tham chiếu qua các solution và project.
- Xem xét sự chia sẻ source. Đặt những project được chia sẻ cùng một source trong cùng một
solution.
- Xem xét cấu trúc đội. Kết cấu những solution của bạn để thực hiện nó một cách dễ dàng cho các
đội làm việc cùng nhau trên một tập các project.
- Giữ một dãy kết cấu project để dễ dàng nhóm
các project vào trong các solution mà không cần phải thay đổi cấu trúc file hệ
thống hay thư mục source control .
Single
Solution
Nếu bạn làm
việc trong một hệ thống nhỏ, hãy xem xét sử dụng một single Visual Studio solution để chứa tất cả
các project của bạn. Cấu trúc này đơn giản
hoá việc phát triển, vì tất cả các code đã có sẵn khi bạn mở các solution. Chiến
lược này cũng giúp bạn dễ dàng để thiết lập references, bởi vì tất cả các references đều nằm giữa những project trong solution
của bạn. Bạn có thể vẫn còn cần phải sử dụng các tập tin references để tham chiếu
đến các assembly của bên thứ ba, như là mua các thành phần(component) , mà ở
bên ngoài solution của bạn. Hình 3.1 hiển thị phương pháp tiếp cận single
solution .
Hình 3.1 Single Solution Approach
Những lí do
chính để chọn cấu trúc này bao gồm:
- Bạn có thể giữ các build script đơn giản.
- Bạn có thể map(ánh xạ) dể dàng các project có tính phụ thuộc ngang
nhau trong solution.
Bạn nên sử dụng cấu trúc này nếu tất cả các lập
trình viên sử dụng cùng một solution và có cùng một tập các project. Điều này
có thể là một vấn đề cho các hệ thống thống lớn nơi mà bạn muốn tổ chức các project
bằng các hệ thống con hay các chức năng .
Partitioned Solution
Nếu bạn làm
việc với một hệ thống lớn, xem xét việc sử dụng
các multiple solution, mỗi cái đại diện một hệ thống con trong ứng dụng
của bạn. Những solution này có thể được
các lập trình viên sử dụng để làm việc trên những phần nhỏ hơn của hệ thống
mà không có việc load tất cả các code trên tất cả các project. Thiết kế cấu trúc solution của bạn với
bất kì project nào mà có phụ thuộc giữa các nhóm với nhau. Điều này cho phép bạn
sử dụng các project reference hơn là các
file reference. Hãy xem xét luôn việc tạo một tập tin master solution để chứa tất
cả các project. Bạn có thể sử dụng điều này để build toàn bộ ứng dụng của bạn.
Lưu ý: Không
như phiên bản trước của Visual Studio, Visual Studio 2005 dựa theo MSBuild. Hiện thời nó cho phép tạo
những cấu trúc solution mà không bao gồm tất cả các project reference và vẫn
còn build không có các error. Miển là master solution được build trước, tạo ra
các binary output từ các project,
MSBuild có thể theo sau các project
references bên ngoài những sự ràng buộc của solution và build thành công của bạn.
Nó chỉ làm việc nếu bạn sử dụng project references, không phải là file
references. Bạn có thể build thành công các solution được tạo bằng phương pháp
này từ Visual Studio build theo các dòng lệnh và từ IDE, nhưng mặc định là
không được với Team Build . Để build thành công với Team Build
hãy sử dụng master solution bao gồm tất cả các project và các phụ thuộc.
Hình 3.2 Hiển
thị phương pháp tiếp cận partitioned solution.
Hình 3.2
Partitioned Solution Approach
Khi làm việc
với các multiple solution, sử dụng một dãy cấu trúc các file cho tất cả các project của bạn. Một thí
dụ điển hình là một ứng dụng có một Microsoft Windows® Forms project, một ASP.NET project, một Windows service, và một tập các class library
project được chia sẻ bởi một hay tất cả
các project này.
Bạn có thể sử
dụng dãy các cấu trúc sau cho tất cả các project:
§ /Source
- /WinFormsProject
- /WebProject
- /WindowsServiceProject
- /ClassLibrary1
- /ClassLibrary2
- /ClassLibrary3
- Web.sln
- Service.sln
- All.sln
Giữ dãy các
cấu trúc này cung cấp nhiều sự linh hoạt và khả năng để sử dụng các solution
cho các trình bày khác nhau trên những project. Cấu trúc thư mục vật lý xung quanh các file solution này thay
đổi rất khó, đặc biệt nếu bạn nhận ra là bạn cần tái sử dụng lại một class
library từ một solution khác.
Lí do để sử
dụng cấu trúc này bao gồm:
- Hiệu suất được cải thiện khi tải và xây dựng
các ứng dụng sub-solution .
- Các sub-solution có thể được sử dụng để tạo
các ý định trên các tập project dựa trên các đội phát triển con hay các ranh giới của việc chia sẻ code.
- Bạn có thể sử dụng master solution để build toàn
bộ ứng dụng.
- Bạn có thể dễ dàng map(ánh xạ) các phần dependency trên các
project trong mỗi sub-solution.
- Nó giảm sự phức tạp nếu các solution broken
up một cách logic. Thí dụ sự phá vỡ các
solution cùng với các tuyến kĩ thuật và
chức năng đã làm cho các lập trình viên
mới hiểu được một cách dễ dàng solution nào đang được thực thi.
Lí do chính
để không sử dụng cấu trúc này :
- Tăng chi phí cho sự bảo trì các solution. Thêm một project mới có thể đề
ra yêu cầu phải thay đổi các tập tin multiple solution .
Multiple
Solutions
Nếu bạn làm
việc trên một solution rất lớn, yêu cầu
hàng tá các project, bạn có thể gặp phải việc mở rộng giới hạn của các solution . Trong kịch bản
này, di chuyển ứng dụng của bạn vào những multiple solution nhưng không tạo một
master solution cho toàn bộ ứng dụng application bởi vì tất cả các reference
bên trong mỗi solution là các project
references. Những tham chiếu đến các
project bên ngoài mỗi solution (thí dụ cho các libraries hay project của bên thứ ba trong sub-solution khác)
là các file references. Điều này có nghĩa là không thể có "master"
solution.
Thay vào đó,
bạn phải sử dụng một script hiểu trật tự cần phải được built của các solution. Một
trong những nhiệm vụ bảo trì liên quan đến một kết cấu multiple-solution là chắc
chắn rằng những lập trình viên không cố ý tạo ra các vòng tròn tham chiếu(reference)
giữa các solution. Kết cấu này yêu cầu những script(tập lệnh) được thiết kế phức
tạp và những mối quan hệ phụ thuộc rõ ràng. Trong kết cấu này không thể build ứng
dụng trong nó với Visual Studio. Thay vào đó, bạn có thể sử dụng TFS Team Build hay MSBuild một cách trực tiếp.
Hình 3.3 hiển
thị phương pháp tiếp cận multiple solutions.
Hình 3.3
Multiple Solution Approach
Bạn nên sử dụng
kết cấu này để giải quyết sự thực thi Visual Studio IDE và mở rộng các giới hạn
cho các ứng dụng rất lớn.
Một lí do
cho việc không sử dụng cấu trúc này là vì nó yêu cầu một build script phức tạp
để xử lý các phụ thuộc giữa các sub-solutions bằng cách build các solutions theo một trình tự đúng.
Large Project Considerations
Phân biệt những
nhóm phát triển lớn với các nhóm nhỏ hơn theo nhiều cách:
• Họ
đòi hỏi một kết cấu chi tiết và tổng hợp phức tạp hơn.
- Họ có nhiều khả năng hơn về quản lý các thành
phần phụ thuộc trên các solutions và các nhóm projects.
- Họ có nhiều khả năng duy trì các thiết kế cho
các thành phần và các nhóm.
Một phương
pháp tiếp cận partitioned solution làm việc tốt với hầu hết các dự án lớn vì nó
cung cấp các solution một cách mềm dẻo trong khi duy trì một single solution mà
bạn có thể sử dụng để build các ứng dụng. Nếu ứng dụng của bạn đủ lớn để bạn thực
hiện mở rộng giới hạn solution, hãy sử dụng phương pháp multiple solution.
Tổng kết
Sử dụng một
single solution cho các project nhỏ mà các project đó không cần để phân
vùng source của bạn vào các solution con
riêng biệt.
Sử dụng một
partitioned solution cho tập các nhóm project con mà một lập trình viên có thể
chỉnh sửa nó như là một tập hợp, và sau đó tạo một master solution chứa tất cả
các project của bạn.
Sử dụng multiple solutions để tạo một cái nhìn cụ thể
trên những hệ thống con và để giảm việc load và thời gian build của ứng dụng của
bạn.
Một partitioned
solution làm việc tốt với hầu hết các dự án lớn vì nó cung cấp các solution một
cách mềm dẻo trong khi duy trì một single solution mà bạn có thể sử dụng để
build các ứng dụng.
Additional Resources