Windows mobile 仅使用部分移动应用程序就可以阻止WM 6.x开发的社区发布

我正在为一个业务线分布式系统规划一个体系结构，在这个体系结构中，在一个非常相似的用例场景中，必须支持许多不同类型的不同设备

除其他外，我需要提供支持

• 基于Windows Mobile 6.x的PDA
• PC工作站

这些应用程序将提供非常简单的业务逻辑，所以我不想使用过于夸张的架构。然而，我需要支持：

• 远程更新
• PDA（以及可选的PC）的大部分断开连接的客户端场景

在研究适当的参考体系结构时，我偶然发现并扩展了该版本。让我感兴趣的是：

• 断开连接的代理和连接监视器支持大部分断开连接的客户端场景
• 支持更新的Mobile Updater应用程序块

我也知道桌面平台的对应物

现在，这里是我的问题

根据您的经验，VS2008/WM6.x/.NET CF 3.5的MCSF扩展是否足够成熟和稳定，适合生产使用？我不想成为一个知情的受害者，它并不真正适合商业用途，而我在项目的中间。

由于应用程序将非常简单，我不想让MVP模式和其他与CAB相关的框架添加变得过于复杂。我只需要支持上面描述的场景。是否可以使用MCSF社区发布组件，而不必以MCSF的方式构建整个应用程序（使用命令、依赖项注入、MVP等）？我想对于简单的应用程序，我希望保持它的简单

桌面PC应用程序也是如此。我还认为，在这里使用完整的CAB/SCSF将是一个很大的过度，因为这实际上是一组非常简单的要实现的功能，但是我想通过使用更新程序和可能断开连接的客户端块来减少开发时间。没有复杂的UI部分（我将为UI创建简单的WinForms）。可能吗

我也在研究在PC和PDA之间共享一些与断开连接的客户端/远程更新相关的代码的可能性，但我认为MCSF/SCSF不可能实现这一点

我希望在我之前走过这条路的人能给我一个建议：）

MCSF绝对可怕。看起来微软的某个人只是简单地告诉一个没有什么经验的开发人员使用SCSF并在紧凑的框架上“使其工作”。这句话被翻译成“如果它能编译，那就好了”，因为这似乎就是所有发生的事情

它跑吗？当然，但我的老天爷，蝙蝠侠！它在任何现实场景中都是完全不可用的。这已经够糟糕的了，因为它保持（大部分）接口兼容性，并且只包含一组最小的特性

我发现，如果一个应用程序包含2个或更多视图，那么使用MVP模式是值得的。在某个时候，您需要添加另一个视图，并且您已经为此进行了架构。此外，将对象放入DI/IoC框架通常会启用事件聚合之类的功能，我发现即使在无头应用程序中，它也非常有用，因此即使没有任何MVP goo，我最终也会使用它

桌面在我的书中没有什么不同。我创建的IoC库同样支持CF和FFx（以及MonoTouch和Phone 7），因为我跨平台共享了很多代码。我很少创建一个不使用它的桌面项目

---

现在我不是说你必须使用我的国际奥委会项目。我发现它对我遇到的所有问题都很有用，而且我很清楚，当我遇到功能缺失的地方时，我可以很快地添加它（尽管我已经几个月没有发现太多缺失）。如果您觉得舒服或者更喜欢另一个DI/IoC框架，那么最好使用它。我想说的是a）远离与MCSF有关的任何东西，b）使用DI/IoC框架，即使你认为应用程序对一个人来说太简单，因为现实世界中没有太简单而无法从中受益的应用程序。

hmm。。。使用MCSF有点泄气。不过，我会尝试更深一点挖掘。我相信你的话，因为MCSF实在是太可怕了。我将远离它。然而，VS2008/CF 3.5的端口似乎解决了这些问题，至少其中一些问题。正如Daniel在这里所写，他们所做的是从块中删除复合UI应用程序块（CAB），因为它对移动应用程序的性能影响太大，他们设计了移动应用程序块。还有一件事——我想我可以采纳你的建议，甚至在这个简单的场景中，我也可以使用DI/IoC/MVP模型，也许即使使用您的框架，我仍将一无所获，因为我主要关心的是“大部分断开连接的客户端”和“远程应用程序更新”场景的现成实现。您对如何解决这些问题有什么建议吗？Microsoft提供的断开连接和远程更新应用程序块仍然非常有效和有用。只是他们讨厌SCSF/CAB的东西真的很糟糕。谢谢。很高兴知道。有人对移动应用程序块——出租车的替代品——发表评论吗？