2011-09-13 98 views
5

Tôi tự hỏi nếu có một số khuyến nghị đọc, thực hành tốt nhất hoặc ý kiến ​​về cách tổ chức các dự án Java lớn hơn.Cách tổ chức các dự án Java lớn hơn - Dự án so với Không gian tên?

Tôi đã thực hiện các quan sát rằng có những người chia nhỏ mọi thứ thành các dự án (ví dụ: mô-đun) và tạo nhiều dự án chia sẻ web phụ thuộc. Điều này có lợi thế là biên dịch thường là siêu nhanh, nhưng khi dự án lớn thì không ai biết nữa điều gì phụ thuộc vào cái gì và tại sao. Không nói về thư viện phụ thuộc, xung đột phiên bản & co.

Cách khác là chỉ có một vài dự án như giao diện người dùng, chương trình phụ trợ, .... Các không gian tên thực hiện công việc.

Bất kỳ ý kiến ​​nào, bạn có thể đọc thêm ai không?

+0

Chúng tôi sử dụng Maven để quản lý các phụ thuộc và các dự án riêng biệt. Giữ mã nguồn được chia thành các khối có thể thực hiện được và đảm bảo rằng chúng tôi không có thư viện địa ngục. – mcfinnigan

Trả lời

3

Dự án rất lớn sẽ cần phải có một số cách để theo dõi tất cả thư viện và các phụ thuộc khác mà thư viện sử dụng. Tiêu chuẩn defacto để làm điều này là Maven. Đó chắc chắn là cách tốt nhất để bắt đầu theo dõi những gì đang đi vào ứng dụng của bạn.

Sau đó, bạn có thể quyết định cách chia nhỏ ứng dụng của mình. Về cơ bản, những gì bạn đang cố gắng làm ở đây là chia ứng dụng của bạn thành các phần chức năng hoàn chỉnh. Ví dụ: nếu bạn có một trang web có biểu mẫu liên hệ, thư viện ảnh, giỏ hàng và diễn đàn, bạn sẽ chia dự án thành các phần chứa từng mô-đun khác nhau.

+1

Maven là tuyệt vời cho quản lý dự án, nhưng ông có một dự án hiện có, và chi phí của giày-horning dự án của mình vào Maven có thể là một chút cao. Nếu anh ta có thể làm điều đó, tuyệt vời! Nếu anh ta chỉ muốn theo dõi sự phụ thuộc (không có chi phí thiết kế lại việc xây dựng/triển khai của mình để phù hợp với mô hình Maven), Ivy của Apache có ý nghĩa hơn. –

+0

Rất đúng. Tuy nhiên, tôi đã không nhận được ấn tượng mà anh ấy đang hỏi về một dự án hiện có, nhưng thay vào đó là thực hành tốt nhất. Nếu bạn bắt đầu từ đầu, thì tôi sẽ nói Maven. – JCab

+0

Maven là một giải pháp hoàn chỉnh hơn Ivy, vì vậy đó là lý do tại sao tôi sẽ đưa Maven qua Ivy. Từ Apache Website: "Đầu tiên, sự khác biệt quan trọng nhất là chúng không phải ở cùng một loại công cụ. Apache Maven là một công cụ quản lý dự án phần mềm và hiểu, trong khi Apache Ivy chỉ là một công cụ quản lý phụ thuộc, được tích hợp cao Apache Ant ™, công cụ quản lý xây dựng phổ biến. Vì vậy, có thể một so sánh thú vị hơn sẽ so sánh Apache Ant + Ivy với Apache Maven. Nhưng điều này vượt quá phạm vi của trang này chỉ tập trung vào quản lý phụ thuộc. " – JCab

5

Ngay sau khi bạn bắt đầu tách một dự án lớn thành các dự án nhỏ hơn, bạn gặp phải rất nhiều sự theo dõi phụ thuộc mà bạn thường không phải xem xét. Bạn có thể tự mình quản lý hoặc bạn có thể sử dụng phần mềm đã xử lý rất nhiều vấn đề cốt lõi.

I would recommend Apache's Ivy. Nó tích hợp tốt với Ant của Apache, và có một tệp cấu hình riêng biệt (được kiểm tra) để theo dõi những gì được yêu cầu cho mỗi loại xây dựng.

Maven của Apache là một lựa chọn tốt khác; tuy nhiên, nó còn nhiều hơn cả Ivy của Apache. Đôi khi "nhiều hơn" có nghĩa là bạn làm ít hơn những gì bạn sẽ làm, đôi khi "nhiều hơn" có nghĩa là bạn đang làm (và cấu hình) những thứ mà bạn không làm trước đây. Tùy thuộc vào sự phù hợp của thực hành của bạn với Maven, việc di chuyển sang Maven có thể dễ dàng hoặc rất khó.

Ngoài ra, bằng cách sử dụng Ivy, bạn có thể thiết lập kho lưu trữ riêng tư của các tệp jar "được phép" của bạn để kéo và điều này sẽ giúp việc kiểm tra mã dễ dàng hơn nhiều. Về cơ bản, cấu hình lại ivy để không kéo từ web, nhưng để kéo từ kho lưu trữ cục bộ của bạn, và sau đó kiểm soát truy cập vào kho để chỉ cho phép các tệp jar được xem xét để có giấy phép chấp nhận được.

Khi bạn đã cài đặt phần mềm, bạn có thể chia nhỏ các dự án thành nhiều phần nhỏ hơn. Điều này sẽ cho phép bạn làm điều đúng (nếu dự án của bạn ủng hộ phân hủy nhỏ) thay vì điều cần thiết (một vài khối lớn có thể không thực sự mua cho bạn nhiều trong khả năng bảo trì phân hủy). Theo như nơi để thực hiện việc cắt giảm, điều đó phụ thuộc rất nhiều vào các chi tiết cụ thể của ứng dụng của bạn.

Nhiều phần nhỏ có xu hướng dễ dàng hơn cho một người mới để tiêu hóa từng người một. Họ cũng giúp mọi người suy nghĩ về chức năng được thêm vào một dự án; tuy nhiên, nó tốn thời gian và công sức để tháo gỡ và tách rời tất cả các thành phần. Mặt khác là nói chung dễ kiểm tra và xác nhận điều gì đó nhỏ hơn, nhược điểm là nó là một con đường dài hơn để phân hủy một bộ sưu tập nguyên khối thành nhiều đơn vị nhỏ, tích hợp nhưng có chức năng khác nhau.

Chúc may mắn

1

Thực ra, bạn sẽ muốn sử dụng cả dự án và không gian tên.

Không gian tên là một công cụ quan trọng để phân biệt mục đích của mã ở cấp mã. Bất kể những gì dự án một lớp đến từ, gói phần mềm nên cho tôi một số ý tưởng về mục đích của nó.

Ở cấp độ cao hơn, việc quản lý các bản dựng và môi trường phát triển của bạn dễ dàng hơn bằng cách tách mã của bạn thành các dự án. Ví dụ, nếu bạn đang phát triển một giao diện người dùng, tại sao bạn cần phải có mã cơ sở dữ liệu được nạp vào IDE của bạn? Nó chỉ là lộn xộn thêm trong không gian làm việc của bạn. Nó cũng làm cho nó đơn giản hơn để chia sẻ chức năng chung giữa các dự án khác nhau. Điều này tất nhiên sẽ dẫn đến việc cần một số hình thức quản lý phụ thuộc, trong đó một trong những công cụ được đề cập như Maven hoặc Ivy sẽ đủ.

Một lưu ý quan trọng là mặc dù. Không sử dụng các gói tách giữa các dự án. Điều này gây ra những cơn ác mộng nếu bạn hoặc bất kỳ ai sử dụng mã của bạn muốn làm như vậy trong môi trường OSGi. Vì vậy, không gian tên của bạn nên là duy nhất trong một dự án, mặc dù chúng nên chia sẻ một gốc chung với các dự án liên quan khác.

Các vấn đề liên quan