It should be viable, but you're gonna have to really think the communication model through. The SaaS scenario is the most restrictive and security sensitive, so you should start from there and scale back to the all-local setup.
I'd advise against RIA services. As often is the case with MS it's nice for simple stuff, but you'll soon enough run into it's restrictions and then curse it. See here for how to do Message Security in SL.
As in Question 2: I wouldn't go with RIA, but even if you do, you can use Entity Framework and keep it DBMS agnostic.
I for one am a fan of stored procedures. Yes, it creates multiple points of deployment (and the inherent risk of version differences), but I always say "keep SQL in SQL".
Unfortunately what you're describing is a common issue in TDD of interfacing systems. I'd use a mockup client to test the server and then use the real server to test the client.
Here is what we've ended up choosing for our LOB - local/client-server/saas app :
This turned out to be extremely viable. We have very few exceptions, most of the codebase is exactly the same, for local, client server and saas.
We decided not to go with WCF RIA, but to use regular WCF Calls, we are using "TransportWithMessageCredential" to secure the communication.
We are using Entity Framework for exposing the database to our backend application. There we have our domain layer and our custom "Entity" classes, which we fill based on the EntityFramework Classes we get.
Since we are using Entity Framework, our SQL statements are all completely gone. We are using Linq to select what we want. So far this is working great. So no more inline SQL. And by introducing separate layers (Entity Framework -> Context class -> Mapper Class -> Entity Class) we have a high maintainability.
We have dumbed-down the frontend as much as possible. The ViewModels we have there are strictly used for filling all the bound-properties so the View has data to work with. All the decissions with regards to what data or what is possible are being done in the backend. The entire flow of the application is run by a Manager class in the backend which uses a WCF Duplex connection to tell the frontend what to do.
发布评论
评论（2）
它应该是可行的，但你必须认真考虑沟通模型。 SaaS 场景是最受限制且安全敏感的，因此您应该从那里开始并缩减到全本地设置。
我建议不要使用 RIA 服务。与 MS 的情况一样，它对于简单的东西来说很好，但很快你就会遇到它的限制，然后诅咒它。请参阅此处 了解如何在 SL 中实现消息安全。
如问题 2 所示：我不会选择 RIA，但即使您这样做，您也可以使用实体框架并使其
我是存储过程的粉丝。是的，它创建了多个部署点（以及版本差异的固有风险），但我总是说“将 SQL 保留在 SQL 中”。
不幸的是，您所描述的是接口系统 TDD 中的一个常见问题。我会使用模型客户端来测试服务器，然后使用真实服务器来测试客户端。
It should be viable, but you're gonna have to really think the communication model through. The SaaS scenario is the most restrictive and security sensitive, so you should start from there and scale back to the all-local setup.
I'd advise against RIA services. As often is the case with MS it's nice for simple stuff, but you'll soon enough run into it's restrictions and then curse it. See here for how to do Message Security in SL.
As in Question 2: I wouldn't go with RIA, but even if you do, you can use Entity Framework and keep it DBMS agnostic.
I for one am a fan of stored procedures. Yes, it creates multiple points of deployment (and the inherent risk of version differences), but I always say "keep SQL in SQL".
Unfortunately what you're describing is a common issue in TDD of interfacing systems. I'd use a mockup client to test the server and then use the real server to test the client.
以下是我们最终为 LOB 选择的内容 - 本地/客户端服务器/saas 应用程序：
事实证明这是非常可行的。我们几乎没有例外，对于本地、客户端服务器和 SaaS 来说，大多数代码库都是完全相同的。
我们决定不使用 WCF RIA，而是使用常规 WCF 调用，我们使用“TransportWithMessageCredential”来保护通信。
我们正在使用实体框架将数据库公开给我们的后端应用程序。在那里，我们有域层和自定义“实体”类，我们根据获得的 EntityFramework 类填充它们。
由于我们使用了实体框架，我们的 SQL 语句完全消失了。我们使用 Linq 来选择我们想要的内容。到目前为止，这效果很好。所以不再有内联 SQL。并且通过引入单独的层（实体框架 -> Context 类 -> Mapper 类 -> 实体类），我们具有很高的可维护性。
我们已经尽可能简化了前端。我们拥有的 ViewModel 严格用于填充所有绑定属性，以便视图可以使用数据。所有关于什么数据或什么可能的决定都是在后端完成的。应用程序的整个流程由后端的 Manager 类运行，该类使用 WCF Duplex 连接来告诉前端要做什么。
Here is what we've ended up choosing for our LOB - local/client-server/saas app :
This turned out to be extremely viable. We have very few exceptions, most of the codebase is exactly the same, for local, client server and saas.
We decided not to go with WCF RIA, but to use regular WCF Calls, we are using "TransportWithMessageCredential" to secure the communication.
We are using Entity Framework for exposing the database to our backend application. There we have our domain layer and our custom "Entity" classes, which we fill based on the EntityFramework Classes we get.
Since we are using Entity Framework, our SQL statements are all completely gone. We are using Linq to select what we want. So far this is working great. So no more inline SQL. And by introducing separate layers (Entity Framework -> Context class -> Mapper Class -> Entity Class) we have a high maintainability.
We have dumbed-down the frontend as much as possible. The ViewModels we have there are strictly used for filling all the bound-properties so the View has data to work with. All the decissions with regards to what data or what is possible are being done in the backend. The entire flow of the application is run by a Manager class in the backend which uses a WCF Duplex connection to tell the frontend what to do.