Lightswitch 应用程序框架似乎引起了轰动。阅读一些帖子/论坛/文章并收听视频提供了一些答案，但提出了一些其他问题。
可扩展性？ 是否有几个钩子可以覆盖或扩展功能？
模块化？可以集成 MEF/Prism 吗？是否有可以在运行时加载的动态模块的概念？
可本地化？关于不同语言本地化的任何特殊功能？
可版本化？任何版本的概念，以便同时版本可以共存？
抽象？可以抽象和替换与数据源的连接吗？
可测试性？不同的组件是否可以以自动化的方式进行单元测试？实现容易还是难？
横切/NFR ? 有什么钩子可以让我们插入 NFR 代码吗？（日志记录、缓存、审计、安全）
这是构建一些 PAAS 应用程序的可靠框架吗？
让我根据我刚刚做的评估给你我的 2 美分：
可扩展性
您当然可以添加自定义控件，显然会有一个已发布的可扩展性 API。
模块化
不，Lightswitch 不是代码生成器，它抽象了 UI 的实现。
可本地化
没有看到任何东西，但我想这将分阶段发生。
可版本化？
您可以对 Lightswitch 项目进行 TFS，但如果您的意思是从执行的角度进行版本控制……这就像将应用程序的新版本部署到服务器一样简单。据我了解，客户端将在运行时检查更新并根据需要进行安装。
抽象
是的，如果您在 WCF RIA 服务层抽象它，这很容易做到。
可测试性
业务规则可以在 RIA 服务层实现，因此测试应该很容易，但如果您严重依赖通过 UI 驱动的规则，您将不得不使用另一个基于 UI 的测试工具。
横切/NFR
如果您专注于让应用程序的 RIA 服务层成为业务规则的中心位置，并让 UI 只专注于用户体验，那么您将不会遇到太多重叠。我认为 Lightswitch 是许多解决方案的好客户端，但它的核心功能是将其用作 RIA 服务的客户端，而 RIA 服务本身完全不依赖于 Lightswitch。
我希望我至少提供了一些有用的见解。
可扩展性？当内置 LS 控件无法满足您的需求时，您可以使用几乎任何 Silverlight 控件（包括 3rd 方控件），或创建您自己的自定义 Silverlight 控件。与使用 LS 控件相比，还有一些工作要做，因为 LS 控件内置了一些额外的“智能”，因此您可以将它们放在屏幕上、绑定并使用它们。框架中还内置了一些扩展点，允许您创建自己的“扩展”（外壳、控件、主题等）。
模块化？LS 已经在幕后使用了 MEF，因此它很有可能在未来被进一步利用。LS确实生成代码，但为自己生成代码，而不是为外部消耗。然而，微软的 Eric Erhardt 有一篇很棒的文章
这显示了如何重用 LS 构造的数据模型（在 Eric 的案例中，他使用它来创建一个 RIA 服务，该服务聚合数据以在图表控件中呈现）。
可本地化？我不相信目前有任何内置的本地化功能。
可版本化？对于基于 Web 的应用程序，如果数据架构没有改变，我不明白为什么不能发布单独的版本，但桌面 (OOB) 应用程序是单击一次应用程序，因此受该技术的约束。
抽象？如果要为数据源创建 RIA 服务，则可以抽象出实现细节。
可测试性？不幸的是，V1 在编写时并没有考虑到“可测试性”。如果您将业务逻辑提取到 Silverlight 类库（用于客户端，或完整的 .NET 类库以用于服务器），您可以对该逻辑进行单元测试，但您在 LS 应用程序本身中编写的代码是目前还不能真正进行单元测试。