寻找J2ME友好的IoC容器已经开启！

我正处于Blackberry/J2ME项目的开始阶段 - 除了这个美妙的平台带来的其他局限性，缺少对反射和1.3语言级别的支持意味着绝大多数现有IoC容器都不可用。（Google没有AOP的Guice for Android，但即使这样也需要支持注释）。寻找J2ME友好的IoC容器已经开启！

所以J2ME上IoC容器的空间相当有限。引起我注意的一个框架被称为Signal Framework，它看起来很有希望。它试图保持概念上接近Spring Framework的IoC，实现它的一小部分功能，并且不依赖于字节码修改或导致运行时XML解析。相反，它在构建时处理配置XML以生成实现此IoC功能的Java代码。

一般来说，代码生成在编译的时候似乎是移动应用的非常明智的做法 - 如果我的应用程序必须做用户的设备上少XML解析，这是伟大的呢！

那么，是什么一直对J2ME/CLDC实现的IoC您的经验，以及如何是你能熄灭你的嘴苦味？

来源

2009-06-22 Paul Milovanov

Signal Framework它是。

更新：不幸的是，信号非常煮熟的现在，所以我打算用Israfil IOC自定义添加。

来源

2009-07-14 19:56:02

在J2ME中你需要减少你使用尽可能减少JAR文件的大小类的数量。这导致许多设计妥协，其中最重要的是灵活性。

这是不容易的，当你不得不放弃的你虽学到的东西必须（和来高度重视）关于OO窗外调整到J2ME开发。事实是，如果您希望可以在大量手机上运行的应用程序，您需要对设备的限制非常敏感。

因此，我认为IoC框架不会满足许多人对J2ME开发的需求。

来源

2009-06-24 19:35:19 Grouchal

Dankeshön为您提供洞察，Grouchal :)我同意您在J2ME上放弃一些应用程序设计偏好的想法。然而，我认为自己可以负担得起使用IoC框架的原因是，我正在开发的应用程序将针对基于CLDC的更强大的设备，如S60上最新的Blackberry和J2ME（以及Android，还有一些MODS）。 – 2009-06-25 22:04:38

当CLDC 1.0被构思时，CLDC 1.0所强加的限制背后的想法非常棒;然而，今天，似乎大多数感兴趣的设备功能更强大，并且具有更多的存储空间。因此，我们是否可以将良好的开发实践（如IoC的使用）转移到移动Java开发的问题上是非常自然的。如我所说，如果这可以通过构建时生成代码而不是在运行时完成，并且可以显着改进代码组织的清晰度 - 为什么不使用它？ – 2009-06-25 22:07:19

您可能有兴趣查看FallME。尽管我没有亲自使用它，但它似乎是专门为J2ME平台构建的无意义框架。

来源

2009-07-27 08:34:33 paracycle

我一个荷兰壶会议期间在Spring ME来（与它没有任何经验）。

来源

2009-07-27 21:54:14

我们在TomTom使用了Spring ME。它工作得很好。

来源

2009-08-13 18:54:04

寻找J2ME友好的IoC容器已经开启！

回答

相关问题