2010-02-24 70 views
23

Tôi đang làm việc trên bộ sản phẩm có 4 sản phẩm. Ngay bây giờ, tất cả dữ liệu cấu hình nằm trong tệp XML hoặc thuộc tính. Cách tiếp cận này không thể duy trì vì chúng tôi phải quản lý tệp cấu hình khác nhau cho môi trường khác nhau (ví dụ: Sản xuất, Phát triển, v.v.).Cách tốt nhất để quản lý dữ liệu cấu hình

Vì vậy, cách tốt nhất để xử lý dữ liệu cấu hình là gì?

Ngoài ra, chúng tôi có thể mô đun hóa mô-đun này thành một mô-đun riêng biệt không? Vì vậy, tất cả các sản phẩm có thể sử dụng mô-đun này. Chúng tôi không muốn sử dụng các tệp thuộc tính. Tôi đang tìm một giải pháp trong đó chúng ta có thể di chuyển tất cả các mã cấu hình cụ thể như là một mô-đun cấu hình mới và lưu giữ tất cả dữ liệu cấu hình trong cơ sở dữ liệu.

+0

Bạn không chắc chắn tôi hiểu câu hỏi về các mô-đun? – Nicole

+0

Chúng tôi không muốn giữ dữ liệu cấu hình trong thuộc tính hoặc tệp xml.Chúng tôi muốn tập trung dữ liệu này vào cơ sở dữ liệu. Vì vậy, tôi nghĩ về việc tạo ra một mô-đun riêng biệt trong ứng dụng của chúng tôi sẽ xử lý tất cả các công cụ cấu hình. – Shekhar

+2

có vẻ như tôi đã quyết định không sử dụng các tệp thuộc tính dựa trên thứ gì đó mà bạn không nói cho chúng tôi biết. Bạn có thể cho chúng tôi biết lý do tại sao bạn muốn có các tệp cấu hình duy trì cơ sở dữ liệu không? Bạn sẽ vẫn cần phải có một cái gì đó bên ngoài chỉ đơn giản là để quản lý các thuộc tính cần thiết để thực hiện kết nối cơ sở dữ liệu. – Nicole

Trả lời

20

Sử dụng commons-configuration bạn có một API thống nhất để truy cập vào các tính chất, bất kể có bao họ được đại diện - .properties, xml, JNDI, vv Ví dụ:

config.properties:

jdbcHost=192.168.12.35 
jdbcUsername=dbuser 
jdbcPassword=pass 

config.xml:

<config> 
    <jdbcHost>192.168.12.35</jdbcHost> 
    <jdbcUsername>dbuser</jdbcUsername> 
    <jdbcPassword>pass</jdbcPassword> 
</config> 

trong cả hai trường hợp, chúng sẽ có thể truy cập được th something like:

String host = config.getString("jdbcHost"); 
+5

Tôi không chắc chắn, nhưng có vẻ như không phải là điều này trả lời câu hỏi của OP. OP dường như biết cách lấy các giá trị từ tệp XML hoặc các tệp thuộc tính - nhưng có vấn đề với việc duy trì nhiều tập tin cấu hình. – Nicole

+0

sau khi cập nhật của nó là một chút rõ ràng hơn. không phải lúc đầu. Và dù sao, cấu hình commons giúp duy trì nhiều tập tin cấu hình. – Bozho

12

Bạn sắp hoàn thành ... Tôi sẽ giữ nguyên cách tiếp cận của bạn và kéo tệp cấu hình đúng cho phiên bản ứng dụng đang chạy theo một phương pháp tương tự :

  1. Tên tất cả các tập tin cấu hình của bạn khác nhau và có ứng dụng của bạn kéo chúng bằng một số tiêu chí độc đáo (username, hostname, vv):

    • sản .properties
    • developer1 .properties
    • developer2 .properties
  2. Giữ chúng ngoài codebase ở một vị trí dựa trên một biến môi trường mà các ứng dụng giả định tồn tại:

    • YOURAPP_CONFIG_DIR /server_config.xml
    • YOURAPP_CONFIG_DIR /database_config.properties

Tôi thậm chí đã sử dụng một sự kết hợp của những phương pháp trên cùng một dự án (# 1 cho các cấu hình quá trình xây dựng và # 2 cho các cấu hình thời gian chạy).

+0

Cách tiếp cận # 1 nơi bạn đề nghị đặt các tệp cấu hình trong một dự án maven hoặc cấu hình không được đặt trong cùng một mã repo? – tuk

3

Đối với tất cả các môi trường của chúng tôi, dữ liệu cấu hình tồn tại trên các máy mục tiêu dưới dạng tệp thuộc tính.Chúng tôi sử dụng PropertyPlaceholderconfigurer từ SpringFramework để ràng buộc các thuộc tính này với ứng dụng của chúng tôi để giữ mọi thứ di động trong môi trường.

Ví dụ, miễn là tôi biết rằng /etc/myapp/database.properties sẽ có mặt trên bất kỳ máy ứng dụng của tôi sẽ được chạy trên, sau đó trong cấu hình mùa xuân của tôi, tôi chỉ cần một cái gì đó giống như vậy:

<bean id="myPropertyConfigurer" 
    class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
    <property name="locations"> 
     <list> 
      <value>/etc/myapp/database.properties</value> 
     </list> 
    </property> 
</bean> 
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource"> 
    <property name="driverClassName" value="com.mysql.jdbc.Driver" /> 
    <property name="url" 
     value="jdbc:mysql://${db.host}:3306/${db.name}" /> 
    <property name="username" value="${db.user}" /> 
    <property name="password" value="${db.pass}" />  
</bean> 

Có một loạt tùy chọn cho lớp Spring đó về nơi tệp thuộc tính có thể phát trực tiếp. Bạn thậm chí có thể làm cho họ thay thế và vượt qua chúng trong như biến môi trường:

<bean id="myPropertyConfigurer" 
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
    <property name="searchSystemEnvironment" value="true" /> 
    <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" /> 
    <property name="locations"> 
     <list> 
      <value>${database.configuration.file.url}</value> 
     </list> 
    </property> 
</bean> 

Và trong bash_profile (hoặc bất kỳ): JAVA_OPTS xuất khẩu = "-Ddatabase.configuration.file.url = file: /// etc/myapp/database.properties "

Hoặc chỉ tùy chọn -D được chuyển vào khi bạn gọi" java "tùy thuộc vào việc bạn đang làm.

FWIW, chúng tôi duy trì các tệp thuộc tính riêng lẻ dưới dạng RPM.

4

Nếu ứng dụng của bạn làm việc với một cơ sở dữ liệu, bạn có thể tạo ra một "cấu hình" bảng như sau:

create table configuration (mode char(3), key varchar(255), value varchar(1023)); 

Bạn sẽ khởi tạo nó sử dụng một init script, nói init.sql với nội dung dọc theo dòng:

insert into configuration values ('pro', 'param1', 'value1'); -- production 
insert into configuration values ('dev', 'param1', 'value1'); -- development 
insert into configuration values ('tst', 'param1', 'value1'); -- testing 
... 

những lợi ích của phương pháp này như sau:

  • bạn phiên bản kịch bản togeth er với mã của bạn
  • bạn có thể dễ dàng mở rộng nó để bao gồm cho mỗi người dùng hoặc mỗi nhóm cài đặt bằng cách thêm một người dùng/nhóm id
  • bạn có thể thay đổi các thiết lập tại runtime nếu bạn cần phải làm như vậy
  • bạn có thể sử dụng cùng một ngăn xếp (JPA + DAO, Cayenne ...) bạn thường sử dụng để dữ liệu ứng dụng cốt lõi xử lý để dữ liệu cấu hình xử lý
+5

Và làm thế nào để bạn đọc các tham số cấu hình để kết nối với cơ sở dữ liệu? :-) – PhiLho

+0

Tại sao mã hóa cứng, tất nhiên! Trên một lưu ý nghiêm trọng hơn, có một tập tin cấu hình "bootstrap" để lưu trữ thông tin truy cập DB là tốt, miễn là một DB được sử dụng để lưu trữ cấu hình khác, gặt hái những lợi ích trên. –

2

có rất nhiều chiến lược khác nhau. Tất cả đều tốt và phụ thuộc vào những gì phù hợp với bạn nhất.

  1. Tạo một tạo phẩm duy nhất và triển khai cấu hình cho một vị trí riêng biệt. Tạo phẩm có thể có các biến chỗ dành sẵn và, khi triển khai, cấu hình có thể được đọc. Hãy xem xét trình giữ chỗ thuộc tính Springs. Nó hoạt động tuyệt vời cho các ứng dụng web sử dụng Spring và không liên quan đến việc tham gia các hoạt động liên quan.
  2. Có cấu hình thuộc tính bên ngoài được cài đặt bên ngoài ứng dụng web. Giữ cho vị trí không đổi và luôn đọc từ cấu hình thuộc tính. Cập nhật cấu hình ở bất kỳ giai đoạn nào và khởi động lại sẽ tăng các giá trị mới.
  3. Nếu bạn đang sửa đổi môi trường (tức là máy chủ ứng dụng đang được sử dụng hoặc quyền của người dùng/nhóm), hãy xem xét sử dụng các phương pháp trên với con rối hoặc đầu bếp. Cũng có một cái nhìn tại quản lý các tập tin cấu hình của bạn với những công cụ này.
-4

Đây là giải pháp ngu ngốc đơn giản.

Đoạn mã, cố gắng sử dụng tệp thuộc tính trong thư mục hiện tại trước tiên. Nếu không thành công, hãy sử dụng tệp thuộc tính trong thư mục tài nguyên (hoặc trong tệp jar).

Properties configFile = new Properties(); 
    try { 
     configFile.load(new FileInputStream("production.properties")); 
    } catch (Exception e) { 
     System.err.println("Can not read properties, try to use default properties file."); 
     configFile.load(this.getClass().getClassLoader(). 
        getResourceAsStream("development.properties")); 
    } 
+3

OP đặc biệt nói rằng anh ta không muốn sử dụng các tệp thuộc tính! –

0

Biến môi trường chỉ là cách dễ nhất để thực hiện. Đặt chúng như bạn làm bất kỳ lúc nào khác, truy cập chúng w/System.getenv("...")

0

Config là công cụ quản lý tệp cấu hình. Bạn có thể tạo cấu hình phổ biến trên tất cả các môi trường hoặc bạn có thể tạo cấu hình môi trường cụ thể. Bạn có thể tiếp tục sử dụng tệp XML và các tệp thuộc tính của mình và để cho Config duy trì sự khác biệt trong môi trường. Bạn có thể nghĩ Config là cơ sở dữ liệu tập trung của bạn và nó có thể xuất tệp cấu hình theo định dạng mà bạn muốn. Bất cứ khi nào bạn muốn tập tin cấu hình của bạn, chỉ cần triển khai (đẩy hoặc kéo) nó từ Config đến vị trí mong muốn của bạn. Lưu ý rằng tôi là một phần của nhóm Config.

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