2009-10-09 25 views
5

Tôi đang cố gắng truy cập vào các thùng chứa IOC và tôi nhận thấy một số lượng lớn trong số đó đang sử dụng cấu hình xml. Bất cứ ai có thể khai sáng cho tôi là tại sao nhiều công nghệ mới đang hướng tới các mô hình lập trình/cấu hình xml (WCF, WPF, Spring.NET, Unity, Windsor)? Có vẻ như xml là một lựa chọn không tốt cho việc xác định các thiết lập phức tạp và nó sẽ tốt hơn để làm điều đó trong mã nơi mọi thứ đều an toàn và chúng ta có intellisense. Tôi biết rằng một số có thể tìm thấy lập luận này, nhưng tôi thực sự tò mò là tại sao những công nghệ tiên tiến khác rất mát mẻ này dựa vào xml.Tại sao xml lại nổi bật trong các thùng chứa IOC?

+1

Vùng chứa IOC phải di chuyển * cách xa * khỏi cấu hình xml. Các hướng rất Structuremap đã đi. Structuremap sử dụng cấu hình thông thạo. Mọi thứ khác chỉ là chơi bắt kịp. ;-) – mxmissile

+3

@mxmissile: Thật tuyệt vời cho đến khi một nhà phát triển không cần thay đổi điều gì đó. Ngoài ra nó dễ dàng hơn để viết công cụ cấu hình xung quanh XML sau đó phong cách mã hóa thông thạo. –

+3

@Được rồi, tôi không hiểu, tôi thấy viết xml giống như móng tay của tôi bị kéo. Cấu hình lưu loát dường như có ý nghĩa trực quan từ một điểm nhìn dev. Ngoài ra, một người không phải là dev có nên chạm vào thứ gì đó như thế này không? – Steve

Trả lời

2

Mọi thứ đã thay đổi trong thế giới Java với các khả năng được cung cấp bằng cách sử dụng chú thích nhưng bạn nên đọc I don't get Spring bởi Bob Lee, tác giả của Google Guice.

EDIT: Như đã đề cập trong nhận xét, không công bằng khi trích dẫn bài đăng trước đó mà không đề cập đến I was too hard on Spring.... Bây giờ đã được sửa. Cảm ơn vì đã nhắc tôi về điều này.

+1

Đừng quên theo dõi, "Tôi đã quá cứng vào mùa xuân" (http://crazybob.org/2006/02/i-was-too-hard-on-spring.html). Có nói rằng, tôi thích DI framework hỗ trợ cả hai kiểu cấu hình. –

+0

Hoàn toàn đúng, tôi đã cập nhật câu trả lời của mình. Cảm ơn. –

2

Vì đó là những gì mọi người khác đang làm trong không gian .net. Nó bắt đầu với web.config và mọi người bắt đầu mở rộng nó. nhưng tôi tin rằng hầu hết các công nghệ đó đều hỗ trợ cả việc cấu hình bằng XML và theo mã. Sự khác biệt chính sẽ là sự dễ dàng mà một người không phải là người quản trị hệ thống có trách nhiệm triển khai một ứng dụng để thay đổi cấu hình. Nếu điều đó là cần thiết thì XML vẫn là một lựa chọn khả thi trong quan điểm của tôi. Tôi tin rằng thế giới .net đang bắt đầu xu hướng theo quy ước trên cấu hình thay vì đặt mọi thứ trong các tệp cấu hình XML.

+0

họ hỗ trợ thực hiện nó trong mã, nhưng hầu hết tài liệu hướng đến việc thực hiện nó trong xml. – Steve

+1

XML trở nên phổ biến trước khi web.config – ima

2

XML schema thể được xác nhận làm cho nó có thể là "mạnh mẽ gõ". Một trong những lý do chính nó là rất phổ biến là nó là khá dễ hiểu và có rất nhiều khung phân tích cú pháp trong khá nhiều bất kỳ ngôn ngữ lập trình mà bạn muốn. Không có gì ngăn cản bạn sử dụng tệp phẳng (chẳng hạn như chiều rộng cố định hoặc CSV), tệp INI, tệp JSON hoặc thậm chí các định dạng nhị phân tùy chỉnh nếu bạn muốn.

XML cũng rất phổ biến becasue hầu hết các khuôn khổ lớn hơn có phương pháp serialization trực tiếp để chuyển đổi từ nội dung XML để một người gốc cấu trúc đối tượng phức tạp đến enviornment.

+0

Tôi nhận ra lược đồ có thể được gõ mạnh mẽ, nhưng tôi có nghĩa là các giá trị trong xml. Ví dụ, nếu tôi nhập nhầm tên của giao diện cho IOC xml. Với việc biên soạn, tôi sẽ biết ngay rằng tôi đã phạm sai lầm. Với cấu hình xml, nó sẽ nổ tung khi chạy, đúng không? – Steve

+0

Chính xác. Tất nhiên nếu bạn đang sử dụng studio trực quan, bạn có thể thêm các phần mở rộng lược đồ vào trình soạn thảo XML để nó sẽ cung cấp cho bạn sự kiểm tra và kiểm tra kiểu. Tôi chắc rằng các trình soạn thảo XML khác có khả năng tương tự. –

+0

Cảm ơn, đó là điều tốt để biết. – Steve

3

Trong IOC và nhiều công nghệ "có thể định cấu hình" khác.

Điều là (là) XML nổi lên như là tiêu chuẩn cho khả năng tương tác của tài liệu.

Vì vậy, thay vì để mọi người tạo định dạng riêng, mọi người đã chấp nhận định dạng "mới".

Rất tốt trong một thời gian, nhưng cuối cùng nó trở nên khó chịu, như bạn chỉ ra.

Giới thiệu về việc xác định mã, đôi khi, mã phải được biên dịch lại để các thay đổi có hiệu lực trong khi XML là văn bản/đồng bằng cho phép sửa đổi mà không cần biên dịch lại.

Các định dạng mới đang nổi lên, nhưng không có định dạng nào có tác động như XML.

6

tôi chuyển cấu hình Unity của tôi vào XML chỉ vì một lý do - Tôi có thể thay đổi cấu hình mà không tái lập mã của tôi. Điều này rất hữu ích trong một số trường hợp.

+1

Đó là lý do tại sao tôi cũng ủng hộ XML: không cần biên dịch lại để thay đổi hành vi của hệ thống (ví dụ: thay thế phụ thuộc, thêm khía cạnh ghi nhật ký, v.v.). Quá xấu những kẻ Java có những thứ như SpringIDE nhưng. Net vẫn không có gì so sánh được. Vì vậy, chúng tôi phải sử dụng XSD và UnitTests. IMO IoC-Container được cấu hình hoàn toàn trong mã và không thông qua các tệp cấu hình bên ngoài (Ninject, LinFu?) Đang thiếu một phần quan trọng của IoC. Để tâm trí của tôi, thuộc tính cũng không phải là con đường để đi: thay vì loại bỏ phụ thuộc từ lớp của bạn, bạn thêm một phụ thuộc vào một container IoC. – tobsen

+0

Đồng ý, nhưng có rất nhiều tác vụ không yêu cầu cấu hình XML, trong trường hợp này, tôi thích sử dụng Ninject để làm mát hơn =) – Restuta

5

Nó giống như tự hỏi tại sao búa có một đầu thép khi bạn thà dán việc cùng nhau.

Lắp ráp ứng dụng tại thời gian chạy từ các tập tin cấu hình tường thuật là mục tiêu, DI bản thân chỉ là phương tiện để đạt được nó.

Nếu bạn có thể mã cấu hình, tại sao lại sử dụng khung công tác IoC? Hãy thiết kế chặt chẽ hơn một chút và tiết kiệm cho mình rất nhiều đau đớn.

4

Nói chung, tôi thích giao diện thông thạo cho IoC, như mxmissile được đề xuất (tôi sử dụng Unity).

Trong khi điều này có nghĩa là chỉ một nhà phát triển mới có thể thay đổi mọi thứ (như Matthew Whited đã chỉ ra), bạn có thường xuyên làm như thế nào để bạn có thể thay thế một lớp học này với lớp khác trong ứng dụng của bạn? Trong những trường hợp đó, bạn có thể chuẩn bị một hộp thoại cấu hình đơn giản (được hỗ trợ bởi bất kỳ kho dữ liệu nào bạn muốn) và có kết quả từ việc kiểm soát cấu hình thông thạo đó. Điều này tránh được những lo ngại về sự mong manh và an ninh. Bởi vì nếu một người dùng cuối vít lên tệp cấu hình của bạn, bạn có thể bị đổ lỗi khi ứng dụng gặp sự cố.

Trường hợp sử dụng chính tôi có để thay đổi cấu hình là để kiểm tra đơn vị. Trong trường hợp đó, tôi có thể chèn thủ công các lệnh giả mạo vào lớp của tôi đang được kiểm tra (đó là những gì tôi thường làm) hoặc làm lại cấu hình thông thạo.

3

Vùng chứa IoC nên được coi là công cụ hiển thị để triển khai/định cấu hình ứng dụng không theo chương trình, thay vì khung lập trình để tạo điều kiện cho mẫu thiết kế IoC.

Do đó, XML được sử dụng chủ yếu là vì hai lý do:

  1. đến một cách rõ ràng hình dung các ngữ nghĩa trong những ứng dụng được xây dựng, chứ không phải là verbalize các thủ tục xây dựng.
  2. để mã cấu hình có thể hoán đổi cho nhau giữa các ứng dụng không đồng nhất bên ngoài cung cấp các tính năng giá trị gia tăng (chẳng hạn như hiển thị cấu hình, xác minh, chuyển đổi và chỉnh sửa). I E. ý định là mở các thùng chứa thông qua việc tích hợp dữ liệu thay vì tích hợp API.

API lưu loát thiếu xác minh lược đồ mô hình dữ liệu và cũng rất khó sử dụng để tích hợp dữ liệu dự kiến, do đó, thậm chí không thể so sánh với cấu hình XML.

Xem XML in IoC containers: A Hell or a Realm để thảo luận thêm.

1

Bạn có thể hoàn tất mã cho xml. Ví dụ, có một plugin eclipse cho các tệp cấu hình Spring trong số những thứ khác cho thấy javadoc thuộc tính được đặt làm chú giải công cụ, cung cấp tự động hoàn thành cho tên của các lớp trong classpath của bạn, đánh dấu bất kỳ tham chiếu bean nào không thể được giải quyết bên trong tệp hiện tại, v.v.

Tệp cấu hình thực sự là một dạng DSL - được thiết kế để thể hiện cấu hình ứng dụng. Điều chỉnh này cho phép thể hiện một số điều dễ dàng hơn. Ví dụ, làm thế nào bạn sẽ đảm bảo tắt ứng dụng thích hợp (một thành phần phải được tắt trước khi depedencies) khi bạn khởi tạo các thành phần trong Java? Làm thế nào bạn sẽ cấu hình một máy đánh chặn xung quanh lớp dịch vụ kinh doanh của bạn? Vì lý do tại sao chúng được thực hiện trong XML, tôi đoán DSL là cần thiết, và XML có lợi ích của một chuỗi công cụ thô sơ hiện có (biên tập viên, trình duyệt tính hợp lệ, trình phân tích cú pháp, ...).

1

Không ai đề cập rằng XML có thể là kết quả của phép chuyển đổi XSLT và các DSL tùy chỉnh có thể được tạo theo cách trên cấu hình IoC đơn giản. Đó là một cách tiếp cận rất mạnh mẽ.

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