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