仅使用部分移动应用程序块社区版本进行 WM 6.x 开发
我正在规划业务线分布式系统的架构，其中必须在非常相似的用例场景中支持不同类型的许多不同设备。
其中，我需要支持
- 基于 Windows Mobile 6.x 的 PDA
- PC 工作站。
这些应用程序将提供非常简单的业务逻辑，因此我不想为其使用过度的架构。然而，我需要支持：
- 远程更新
- 对于 PDA（以及可选的 PC）来说，大多数情况下都是断开连接的客户端场景
在研究正确的参考架构时，我偶然发现了 移动应用程序阻止社区发布 和 Mobile Contribute 对该版本的扩展。让我感兴趣的是：
- 断开连接的代理和连接监视器，以支持大多数断开连接的客户端场景
- 移动更新程序应用程序块以支持更新
我还知道 SCSF 桌面平台的对应项。
现在，这是我的问题
- ，根据您的经验，MCSF 对 VS2008/WM6.x/.NET CF 3.5 的扩展对于生产使用来说是否足够成熟和稳定？当我正在进行项目时，我不想成为知道它并不真正适合商业用途的受害者。
- 由于应用程序将非常简单，因此我不想通过 MVP 模式和其他 CAB 相关框架添加使其变得过于复杂。我只需要支持上述场景。是否可以使用 MCSF 社区发布组件，而无需以 MCSF 方式（使用命令、依赖项注入、MVP 等）构建整个应用程序？我想我会希望对于简单的应用程序保持简单。
- 桌面 PC 应用程序也是如此。我还认为，使用完整的 CAB/SCSF 在这里将是一个重大的杀伤力，因为这实际上是一组要实现的非常简单的功能，但我想通过利用更新程序和可能的断开连接来减少开发时间客户端块。只是没有复杂的 UI 部分（我将为 UI 创建简单的 WinForms）。有可能吗？
我还在研究共享一些与 PC 和 PDA 之间断开连接的客户端/远程更新相关的代码的可能性，但我认为 MCSF/SCSF 不可能做到这一点。
我很感激在我之前走过这条路的人的建议:)
I am in a process of planning an architecture for a line of business distributed system, where many different devices of different types must be supported in a very similar use cases scenarios.
Among others, I will need to support
- Windows Mobile 6.x based PDAs
- PC workstations
Those apps will serve pretty simple business logic, so I do not want to use overblown architecture for it. Yet, I need to support:
- remote updates
- mostly disconnected clients scenario for PDAs (and optionally, for the PC)
While researching for the proper reference architecture, I stumbled upon Mobile Application Blocks Community Release and Mobile Contribute extension to that release. What kept me interested has been:
- Disconnected Agent and Connection Monitor to support the mostly disconnected clients scenario
- Mobile Updater Application Block to support updates
I am also aware of the SCSF counterpart for the desktop platform.
Now, here are my questions
- Is, in your experience, MCSF extension to VS2008/WM6.x/.NET CF 3.5 mature and stable enough for the production use? I don't wan't to be a victim of knowing, that it is not really suitable for business use, while I am in the middle of the project.
- Since the application will be very easy, I do not want to make it overly complicated with the MVP pattern and other CAB related framework additions. I just need to support the scenarios described above. Would it be possible to use MCSF Community Release components without having to architect the whole application in the MCSF manner (with commands, dependency injection, MVP etc.)? I think I will want to keep it simple for the simple application.
- Same for the desktop PC App. I also think, that going for full CAB/SCSF would be a major overkill here, as this is really a very simple set of features to be implemented, yet I would like to cut down on development time by utilizing the updater and possibly the disconnected client blocks. Just without the complicated UI part (I will create plain WinForms for the UI). Would it be possible?
I am also researching the possibility to share some of the code related to disconnected clients/remote updates between the PC and PDA, but I don't think that would be possible with MCSF/SCSF.
I would appreciate an advice from someone who went down that road before me :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
MCSF 绝对是可怕的。看来 Microsoft 中的某个人只是告诉经验不足的开发人员采用 SCSF 并“使其在 Compact Framework 上工作”。这被翻译为“如果它能编译，那就没问题”，因为这就是似乎发生的一切。
它运行了吗？当然可以，但是蝙蝠侠太慢了！它在任何现实场景中都完全无法使用。 我从头开始编写了一个替代品，它保持（大部分）接口兼容性，并且只包含最少的内容，这已经够糟糕的了一组功能。
我发现如果一个应用程序包含 2 个或更多视图，那么就值得使用 MVP 模式。在某些时候，您需要添加另一个视图，并且您已经为其构建了架构。此外，将对象放入 DI/IoC 框架通常可以实现事件聚合之类的功能，我发现即使在无头应用程序中，这也非常有用，因此即使没有任何 MVP goo，我最终也会使用它。
在我的书中，桌面没有什么不同。我创建的 IoC 库同样支持 CF 和 FFx（以及 MonoTouch 和 Phone 7），因为我进行了大量跨平台代码共享。我很少创建不使用它的桌面项目。
现在我并不是说你必须使用我的 IoC 项目。我发现它对我遇到的所有问题都很有用，而且我非常了解它，当我遇到功能缺失的区域时，我可以快速添加它（尽管我在几个月内没有发现缺少太多）。如果您觉得舒服或者更喜欢另一个 DI/IoC 框架，那么很好，使用它。我的意思是 a) 远离任何与 MCSF 有关的东西 b) 使用 DI/IoC 框架，即使您认为该应用程序对于一个人来说太简单了，因为不存在真正的应用程序这样的东西这太简单了，无法从中受益。
MCSF is absolutely horrible. It appears that someone in Microsoft simply told a developer with little experience to take the SCSF and "make it work" on the Compact Framework. That was translated as "if it compiles, then it's fine" because that's all that appears to have happened.
Does it run? Sure, but holy slowness Batman! It's completely unusable in any real-world scenario. It's bad enough that I wrote a replacement from the ground up that maintains (mostly) interface compatability and includes only a minimal set of features.
I've found that if an app contains 2 views or more, then it's worth using the MVP pattern. At some point you'll need to add another view and you'll have already architected for it. Also, putting your objects into a DI/IoC framework often enables things like event aggregation, which I find terribly useful even in headless applications, so even without any MVP goo I end up using it.
The desktop is no different in my book. The IoC library I created supports both the CF and FFx identically (as well as MonoTouch and Phone 7) as I do a lot of code sharing across platforms. It's rare that I create a desktop project where I don't use it.
Now I'm not saying that you have to use my IoC project. I find it useful for all the problems I hit, and I know it well enough that when I hit a missing area of functionality, I can quickly add it (though I've not found much lacking in months). If you're comfortable or prefer another DI/IoC framework, then great, use that. What I am saying is a) run screaming away from anything that has to do with MCSF and b) use a DI/IoC framework, even if you think the app is too simple for one becasue there's no such thing as a real-world app that is too simple to benefit from it.