选择正确的.NET体系结构。WCF?wpf/表单,asp.net(mvc)?

桌面用户界面技术

wpf功能强大,无疑是您所描述的应用程序类型的最佳选择。如果您的团队在几个月的学习曲线中没有wpf经验,但是提高生产力和可维护性的长期好处使它非常值得。这个 只有 除了wpf之外,您可以考虑其他任何事情的原因是,如果您的截止日期很紧,并且您的团队已经非常了解其他一些技术。即使在这种情况下,我也会考虑并行开发wpf版本,并将另一个版本视为一个原型。

有些人使用silverlight而不是wpf进行桌面开发,他们认为应该使用一种技术而不是两种技术。我不同意这种观点:这两种技术非常相似,技能和代码传输非常好,wpf目前在silverlight中缺少许多非常有用的功能,随着silverlight获得这些功能,它往往会从wpf中复制出好的东西。因此,从长远来看,在开发wpf应用程序时花费的任何精力和创建的代码都不会浪费。

还要注意,wpf可以在浏览器中运行,就像在silverlight中一样。当我为运行windows的客户机创建web应用程序时,我选择wpf而不是silverlight。我目前正在将一组windows应用程序转换为wpf web应用程序,以便于部署。

web用户界面技术

如果可以使用Silverlight,那么在Web应用程序上使用ASP.NETMVC将是一个傻瓜。在ASP.NET MVC中花费数天的内容在Silverlight上花费数小时或数分钟。在Silverlight中花费数天的时间在ASP.NET MVC中花费数年的时间。

Silverlight的市场渗透率目前约为50%,每月增长2-3%,它将在99%的台式机上运行。到明年,渗透率可能达到85%或更高。您必须权衡少数用户无法下载Silverlight和无法访问您的应用程序的风险与与ASP.NET MVC相关的风险:使用ASP.NET MVC,您的应用程序开发成本将大大增加,上市时间将更长,功能更少,而且“丰富性”也将降低。

也就是说,如果有一个合同,我真的,真的,真的很想要,而且客户不喜欢使用Silverlight,我可能会回到ASP.NETMVC作为我的第二选择。但前提是应用程序的web部分相对较小。

通信技术

wcf是提供数据的好选择。目前它比竞争对手更好,速度更快,并且与Silverlight、XBAP和WPF很好地集成。如果你没有令人信服的理由选择不同的web服务技术,我会选择wcf。

就效率而言,wcf的二进制格式化程序与您所能找到的任何东西一样高效,而且对于您将遇到的使用模式,它比典型的直接数据库访问协议(如tds)更高效。如果必须使用soap格式化程序来实现兼容性,那么在转换为xml时会损失一些带宽,但在其他情况下,它是相对有效的。

我使用了一个叫做“祖母绿数据基础”的数据层,我在接下来的几个月里建立了自己并计划开源。它在web服务和客户机上使用相同的对象,无论是否连接到后端数据库,其行为都相同。这工作得很好,因为你很难意识到有一个通信层。这种方法使得数据层非常简单。

祖母绿数据基础也有一个基于角色的访问控制机制,它允许客户机根据数据对象之间的关系授予对数据的访问权,因此,例如,一个人只能访问他们自己的客户数据。这是在数据层强制执行的,因此任何ui层开发都不能意外地公开不应该看到的数据或进行未经授权的更新。

这个设计看起来非常可行。

wcf是服务层的一个很好的候选者,很高兴看到orm时代的到来,而且您有充分的理由拥有基于表单和基于web的ui。

wpf可以(本质上)像windows窗体一样工作。不过,如果你在写新的东西,ms推荐它胜过win表单。

net mvc是一个很好的基于web的东西的候选者-页面是无状态的,你可以对页面有更多的控制。

查看单独的“wpf vs winforms”类型讨论以了解更多详细信息。

你考虑过Silverlight+RIA服务吗?--对于具有丰富用户界面的n层系统来说,这是一个自然的选择。您可以将它用于intranet和面向客户机的应用程序。

正如sohnee上面提到的,我认为您的逻辑架构方法非常可靠,我认为wcf是“选择”。我相信你会对演示技术和orm有自己的看法。我将在服务层提供一些项目,这是我在与您的应用程序非常相似的应用程序中花费大量时间的地方:

• 如果你还没有,那就看看AppFabric吧。这是微软托管wcf服务的地方,它为您提供了许多好处,如高速检测和服务管理,而这些都是wcf目前无法提供的。
• 根据您的网络基础设施和业务合作伙伴的基础设施,考虑您可以使用哪种类型的协议(以及相应的wcf绑定)。如果你能使用TCP作为高速传输,只要它能与你的网络一起工作,你的状态就会很好。
• 考虑将msmq集成到逻辑体系结构中,以提供排队和保证的传递。juval lowy在他的wcf书籍中有一些关于msmq集成的优秀材料。
• 现在开始考虑您的服务接口和服务版本控制策略。早期在这些领域做出的决策一旦与业务合作伙伴共享,几乎是不可变的。
• 如果涉及多个业务合作伙伴,请考虑如何保护这些服务。微软的p&p小组刚刚发布了一些关于基于声明的身份和访问控制的非常好的指导,根据您的集成场景,这些指导可能对您非常有用。

希望这有帮助。如果你需要更多的信息,请随时发布后续信息。

如果您的团队还没有使用wpf的经验,我建议在桌面客户机上使用winforms,假设您有日程压力(还有什么项目没有?)wpf非常强大,但它也有一个陡峭的学习曲线。我一直把它用于相对较小的、低可见性的项目,它让我有自由去真正了解该技术应该如何使用,而不是试图把一些东西拼凑在一起,就好像它只是带有更漂亮控件的winforms一样。

我对wcf没有太多经验,但我的理解是,那里也有很多学习曲线。和wpf一样,这取决于你的团队知道什么,你能在学习新技术上投入多少时间。

我将从定义功能需求开始,因为它们可能会影响您的体系结构。您提到了客户应用程序正在更改数据,但这是通过某种审批系统间接进行的。我认为这里最重要的一点是,你将如何表示等待批准的更改。

如果这只是一个数据输入应用程序,您可以简单地构建几个屏幕并使用它。这将是最简单的事情,可以工作。

另一方面,如果数据更改对业务有价值的原因,我将首先考虑构建一个可靠的域模型。然后在上面放一层命令。客户应用程序将发出数据更改命令,如“给用户XXX加薪”,该命令将得到批准,然后进行处理。这样的命令将是您架构中的一流公民。