Xây dựng Kiến trúc Plugin với Adobe AIR

Question

Tôi đang nghĩ đến việc chọn Adobe AIR làm công nghệ triển khai phía máy khách cho một dự án sắp tới. (Sự lựa chọn trước là C# và WPF, nhưng gần đây tôi đã thực sự ấn tượng với Flash/Flex/AIR.)

Nhưng một trong những tính năng quan trọng nhất của sản phẩm của tôi sẽ là kiến ​​trúc plugin, cho phép các nhà phát triển bên thứ ba mở rộng chức năng và GUI theo những cách thú vị.

Tôi biết cách thiết kế kiến ​​trúc trong C#: Trình tải trình cắm thêm sẽ liệt kê tất cả các hội đồng trong thư mục "app/plugins /" cục bộ. Đối với mỗi assembly, nó sẽ liệt kê tất cả các lớp, tìm kiếm các triển khai của giao diện "IPluginFactory". Đối với mỗi plugin được tạo bởi nhà máy, tôi sẽ yêu cầu nó cho các lớp MVC của nó và chụp các phần tử GUI (các mục menu, bảng điều khiển, vv) vào các vị trí thích hợp trong bố cục GUI hiện có.

Tôi muốn thực hiện điều tương tự trong AIR (tải plugin từ hệ thống tệp cục bộ, không phải từ web). Sau khi đọc this article, sự hiểu biết của tôi là có thể, và kiến ​​trúc cơ bản (tải SWF vào ApplicationDomains được đóng hộp cát, vv) rất giống với cách bạn làm trong .NET.

Nhưng tôi tò mò về gotchas.

Nếu bạn đã thực hiện bất kỳ việc tải lớp động nào với trình phát flash (tốt nhất là trong các ứng dụng flash/flex hỗn hợp và đặc biệt trong máy chủ AIR), tôi rất muốn nghe về trải nghiệm của bạn. gặp phải tình huống khó khăn với trình phát flash và với API flash, flex và AIR. Ví dụ, nếu ai đó hỏi tôi cùng một câu hỏi này, nhưng với nền tảng Java trong tâm trí, tôi chắc chắn sẽ đề cập rằng JVM không có khái niệm về "mô-đun" hoặc "hội đồng". Cấp độ tổng hợp cao nhất là "lớp", do đó có thể khó tạo cấu trúc tổ chức trong hệ thống plugin để quản lý các dự án lớn. Tôi cũng nói về các vấn đề với nhiều trình nạp lớp và cách mỗi cá thể duy trì một cá thể riêng biệt của một lớp được nạp (với các static static riêng biệt của nó).

---

Dưới đây là một số câu hỏi cụ thể vẫn chưa được trả lời cho tôi:

1) Các ActionScript "Loader" class có thể tải một SWF thành một ApplicationDomain. Nhưng appdomain đó chứa đựng những gì? Modules? Các lớp học? Các thành phần MXML được đại diện như thế nào? Làm cách nào để tìm tất cả các lớp triển khai giao diện plugin của tôi?

2) Nếu bạn đã tải một plugin vào một ApplicationDomain riêng biệt từ ứng dụng chính, có phức tạp hơn khi gọi mã từ bên trong appdomain khác không? Có bất kỳ hạn chế quan trọng nào về các loại dữ liệu có thể vượt qua lớp trộn lẫn giữa các ứng dụng hay không? Là marshalling prohibitively đắt tiền? Lý tưởng nhất, tôi muốn phát triển phần lớn mã chính của riêng tôi như là một plugin (với ứng dụng chính là ít hơn một trình bổ sung tải plugin) và sử dụng kiến ​​trúc plugin để đưa chức năng đó vào ứng dụng. Điều đó có tác động đến nỗi sợ hãi trong trái tim bạn không?

Answer 1

Luca Tettamanti cho câu trả lời tốt các câu hỏi cụ thể của bạn đã có, vì vậy tôi sẽ chỉ cung cấp một số thông tin bổ sung về chủ đề chung:

Tôi đã thực hiện một API plugin đơn giản cho một ứng dụng Flex sử dụng lớp ModuleManager (và các thứ khác trong gói mx.modules.) Ý chính của nó là bạn phân lớp các plugin từ ModuleBase và sử dụng ModuleManager trong ứng dụng máy chủ lưu trữ để tải chúng. Sau đó, bạn có các plugin thực hiện một giao diện chung (ví dụ: IMyAppPlugin) và sử dụng một số loại facade để đại diện và triển khai giao diện cho ứng dụng máy chủ mà plugin có thể sử dụng (ví dụ: MyAppFacade implements IMyAppFacade.) Bất cứ khi nào plugin được tải, hãy tiêm tham chiếu mặt tiền này vào chúng.

Chủ đề "Modular applications overview" trong Flex 3 giúp có một số thông tin tốt Dưới đây là một đoạn trích (các Subchapter "lĩnh Module" thảo luận về lĩnh vực ứng dụng trong bối cảnh của mô-đun.):

"Theo mặc định, một mô-đun được tải vào miền con của tên miền ứng dụng hiện tại. Bạn có thể chỉ định một miền ứng dụng khác nhau bằng cách sử dụng thuộc tính applicationDomain của lớp ModuleLoader. "

Chủ đề "Using the ApplicationDomain class" đi sâu hơn vào chủ đề miền ứng dụng và bạn chắc chắn nên đọc nó nếu bạn chưa có.

Answer 2

1. Các applicationDomain là giống như một namespace, nó định nghĩa các nhóm lớp và đặt chúng vào một hệ thống phân cấp: một miền có thể trực tiếp truy cập vào những biểu tượng trong phạm vi riêng của mình hoặc trong lĩnh vực phụ huynh, nhưng không ở trẻ em hoặc anh chị em ruột các miền (hoặc tốt hơn: nó không thể làm điều đó trực tiếp - nó phải đi qua đối tượng applicationDomain, yêu cầu định nghĩa của một lớp đã cho); khi tải swf ngoài, bạn có thể quyết định nơi để đặt các ký hiệu mới: tên miền con (mặc định), tên miền mới được gắn vào hệ thống (sử dụng null), tên miền hiện tại, tên miền được đính kèm ở nơi khác phụ huynh của tên miền mới). Lưu ý rằng các ký hiệu mới sẽ không bao giờ ghi đè lên các ký hiệu trong tên miền hiện tại, nhưng cùng một tên có thể tồn tại trong nhiều tên miền. Không may là bạn không thể liệt kê các lớp trong một miền cụ thể (tốt, ít nhất là tôi không biết cách nào để làm điều đó), nhưng giải pháp phổ biến là yêu cầu (như trong "Giao diện Plugin") sự hiện diện của giếng -nhà máy được biết đến trong mỗi swf, sẽ trả về định nghĩa (Class) của plugin hoặc chính plugin đó.
2. Bạn chỉ cần có được một tham chiếu đến đối tượng nào đó (nhà máy), sau đó nó chỉ là một đối tượng khác. Không có marshalling: tên miền nó chỉ là một phân vùng hợp lý của không gian tên (đó là một nhánh cây của miền hệ thống).
3. Không :) Nhưng được cảnh báo: nó có thể dễ dàng biến thành địa ngục cho GC, nơi không sử dụng các miền không sử dụng do các tham chiếu lan truyền trong miền khác. Tôi khuyên bạn nên xem xét khung công tác PureMVC đa lõi, có thể với các đường ống để đảm bảo sự tách biệt chặt chẽ giữa các plugin.

Btw, Flash Player cũng là một khái niệm về miền bảo mật, nhưng tôi thực sự chưa bao giờ chạm vào nó, vì vậy tôi không biết khả năng ở đây là gì.

Answer 3

Đáp lại tuyên bố liên quan đến Java như một kiến ​​trúc plug-in có thể:

Hóa ra Java đã được sử dụng để đưa ra plug-in hệ thống kiến ​​trúc trong nhiều năm. Đối với phía máy khách, khung quản lý mô-đun OSINO Equinox có lẽ là tốt nhất được biết đến. Tại một thời điểm, IDE Eclipse đã cấu trúc lại kiến ​​trúc trình cắm thêm của họ trên đỉnh của Equinox OSGi. IDE Eclipse có lẽ là một trong những hệ thống kiến ​​trúc trình cắm thêm phía máy khách thành công nhất mà đã nghĩ ra - từ quan điểm về tuổi thọ lịch sử cũng như bề rộng của cơ sở người dùng và cộng đồng phát triển trình cắm thêm tiếp theo. Họ cũng cung cấp kiến ​​trúc plugin của họ như là một khuôn khổ nền tảng cho việc tạo ra các ứng dụng phía máy khách tùy ý - RCP Eclipse.

Tôi chỉ phải xen vào điều này bởi vì Java được định vị là một lựa chọn rất yếu cho điều này, nó thực sự thành công hơn bất kỳ môi trường ngôn ngữ/thời gian chạy nào khác. C# .NET, trong đó, tất nhiên, có cơ sở bẩm sinh tốt cho các mô-đun. Là loại mỉa mai, nhưng có bạn có nó.

Đối với Adobe AIR, tôi là dev quản lý dự án này đang được phát minh trên AIR. Trong trường hợp của chúng tôi, khả năng mở rộng mô-đun của chúng tôi sẽ luôn được gửi từ máy chủ web - không phải thư mục cục bộ. Flex có thẻ

<mx:Module/>

để tạo module có thể được nạp kín đáo khi chạy.

Than ôi, sự thất vọng với AIR là thiếu bất kỳ API lớp nào để khởi chạy các ứng dụng khác. Bạn có thể tải một URL để tải một cái gì đó trong trình duyệt mặc định của người dùng, nhưng bạn không thể khởi động, nói, Excel. Cả Java và C# đều có API để khởi chạy các ứng dụng khác như các quy trình bên ngoài.

Answer 4

Bạn đã thử tải các ứng dụng con chưa?
Có tài liệu tốt để thực hiện việc này trong AIR và tôi đã thành công với nó trong vài giờ. Tuy nhiên, việc thực hiện tương tự lại là một câu chuyện khác trong Flex vì vi phạm sandbox giữa ứng dụng con và ứng dụng chính. Tôi đã dành hàng tuần đập đầu vào tường.