灯开关评估和问题
Lightswitch 应用程序框架似乎引起了热议。 阅读一些帖子/论坛/文章并收听视频提供了一些答案，但也提出了一些其他答案。
可扩展性？ 是否有多个钩子可以覆盖或扩展功能？
模块化？MEF/Prism可以集成吗？是否有可以在运行时加载的动态模块的概念？
可本地化？关于不同语言的本地化有什么特殊功能吗？
可版本化？ 有版本概念以便同时版本可以共存吗？
抽象？与数据源的连接可以抽象并替换吗？
可测试性？不同的组件是否可以以自动化方式进行单元测试？实现容易还是困难？
交叉/NFR？有什么钩子可以让我们插入 NFR 代码吗？ （日志记录、缓存、审计、安全性）
这是构建某些 PAAS 应用程序的可靠框架吗？
There seems to have a buzz around the Lightswitch application framework.
Reading some posts/forums/articles and listening to a video provdided some answers, but raised some others.
Extensibility?
Is there several hooks to override or extend features?
Modularity? Can MEF/Prism be integrated? Is there a concept of dynamic modules that can be loaded at runtime?
Localizable? Any special features about localization in different languages?
Versionnable? Any concept of version so simultaneous version can co-exist?
Abstraction? The connection to data source can be abstracted and replaced?
Testability? Are the different components unit testable in an automated way? Easy or difficult to achieve?
Cross-cutting / NFR ? Any hooks so we can plug NFR code? (logging, caching, audit, secuity )
Is this a solid framework to build some PAAS application over?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
让我根据我刚刚所做的评估给你 2 美分：
可扩展性
你当然可以添加自定义控件，显然会有一个已发布的可扩展性 API。
模块化程度
不行。Lightswitch 不是代码生成器，它抽象了 UI 的实现。
Localized
没有看到任何东西，但我想这会分阶段发生。
可版本化？
您可以对 Lightswitch 项目进行 TFS，但如果您指的是从执行角度进行版本控制……这就像将应用程序的新版本部署到服务器一样简单。据我所知，客户端将在运行时检查更新并根据需要进行安装。
抽象
是的，如果你在 WCF RIA 服务层抽象它，这很容易做到。
可测试性
业务规则可以在 RIA 服务层实现，因此测试应该很容易，但如果您严重依赖通过 UI 驱动的规则，则必须使用另一个基于 UI 的测试工具。
横切/NFR
如果您专注于让应用程序的 RIA 服务层成为业务规则的中心位置，并让 UI 仅专注于用户体验，那么您将不会遇到太多重叠。我认为 Lightswitch 对于许多解决方案来说都是一个很好的客户端，但它的核心功能是将其用作 RIA 服务的客户端，而 RIA 服务本身并不依赖于 Lightswitch。
我希望我至少提供了一些有用的见解。
Let me give you my 2 cents based on an eval I just did:
Extensibility
You can of course add custom controls and apparently there will be a published extensability API.
Modularity
No. Lightswitch is not a code generator, it abstracts out implementation of the UI.
Localizable
Did not see anything, but I imagine this will occur in stages.
Versionnable?
You could TFS the Lightswitch project, but if you mean versioning from an execution standpoint ... it's as simple as deploying a new version of the app to the server. The client will check for updates on run and install as necessary from what I understand.
Abstraction
Yes, if you abstract it at the WCF RIA Services layer which is very easy to do.
Testability
Business rules can be implemented at the RIA Services layer so testing there should be a snap, but if you rely heavily on rules driven through the UI you will have to use another UI-based testing tool.
Cross-cutting / NFR
If you focus on getting the RIA Services tier of the app to be the central location for business rules and let the UI just focus on user experience you won't run into much overlap. I think Lightswitch is a good client for many solutions, but the core power of it is using it as a client for RIA Services which itself is not dependent on Lightswitch by any stretch.
I hope I at least provided some useful insight.
可扩展性？当内置 LS 控件不允许您执行所需操作时，您可以使用几乎任何 Silverlight 控件（包括第 3 方控件），或创建您自己的自定义 Silverlight 控件。与使用 LS 控件相比，还有更多的工作要做，因为 LS 控件内置了一些额外的“智能”，因此您只需将它们放在屏幕上，进行绑定即可。使用它们。框架中还内置了可扩展点，允许您创建自己的“扩展”（外壳、控件、主题等）。
模块化？ LS 已经在幕后使用 MEF，因此很有可能在未来进一步利用它。 LS确实生成代码，但是是为了它自己，而不是为了外部使用。不过，微软的 Eric Erhardt 有一篇出色的文章
http://blogs.msdn.com/b/lightswitch/archive/2011/04/08/how-do-i-display -a-chart-built-on-aggreated-data-eric-erhardt.aspx
展示了如何重用 LS 构建的数据模型（在 Eric 的例子中，他使用它来创建一个 RIA 服务，该服务聚合数据图表控件中的演示）。
可本地化？我认为目前没有任何内置本地化功能。
可版本化？对于基于 Web 的应用程序，如果数据架构未更改，我不明白为什么您不能发布单独的版本，但桌面 (OOB) 应用程序是点击式应用程序&因此受该技术管辖。
抽象？ 如果您要为数据源创建 RIA 服务，您可以抽象出实现细节。
可测试性？不幸的是，V1 编写时并没有考虑到“可测试性”。如果您将业务逻辑提取到 Silverlight 类库（用于客户端，或用于服务器的完整 .NET 类库）中，您可以对该逻辑进行单元测试，但是您在 LS 应用程序本身中编写的代码是目前还不能真正进行单元测试。
Extensibility? When the built-in LS controls don't allow you to do what you need, you can use just about any Silverlight control (including 3rd party controls), or create your own custom Silverlight controls. There is a little more work to do than using LS controls, because the LS controls have some extra "smarts" built into them, so you can just drop them on a screen, bind, & use them. There are also extensibility points built into the framework that allows you to create your own "extensions" (shells, controls, themes etc).
Modularity? LS already uses MEF under the covers, so it's quite possible that it may be able to be leveraged further in the future. LS does generate code, but for itself, not for external consumption. There is an excellent article, however, by Microsoft's Eric Erhardt
http://blogs.msdn.com/b/lightswitch/archive/2011/04/08/how-do-i-display-a-chart-built-on-aggregated-data-eric-erhardt.aspx
that shows how to reuse the data model that LS constructs (in Eric's case, he uses it to create a RIA service that aggregates data for presentation in a chart control).
Localizable? I don't believe there are currently any built-in localisation features.
Versionable? For a web-based app, if the data schema didn't change, I don't see why you couldn't publish separate versions, but desktop (OOB) apps are click-once apps & are therefore governed by that technology.
Abstraction? If you were to create a RIA service for your data source, you could abstract away the implementation details.
Testability? Unfortunately, V1 was not written with "testability" in mind. If you extract out your business logic into Silverlight class libraries (for use on the client, or full .NET class libraries for use on the server), you can unit test that logic, but the code that you write in an LS application itself is not really unit-testable at this point in time.