C# 应用程序完全SOA？

完全基于SOA构建大型应用程序明智吗？或者只是一部分？用户帐户登录、会计、gis绘图、销售等

换句话说，用HTML和Javascript为这样一个应用程序构建GUI是明智的吗？该应用程序通过ajax与后端的.NETWeb服务进行所有的交换

---

我认为失去所有的.net.aspx功能（如表单身份验证、视图状态等）是不值得的。但我的同事说，如果我们要采用SOA，前端就不需要.net。但我认为应该有某种平衡。你的底线在哪里？所有对数据库的调用都应该通过web服务吗

我想到了歌曲《如果我有锤子》中的歌词。将软件开发为一系列服务。在我看来，这是最好的系统，有少于即时延迟和有限的带宽，以及访问成本高等（这些显然都是高度主观的）。您不需要完整的SOA，只需要在组件之间进行松散的耦合，我认为这是一个很好的目标

DB调用可以通过一个服务进行，以ADO.NET数据服务为例，但是您必须权衡该服务将提供什么。以缓存为例。一个体面的SOA方法会考虑数据可能需要缓存以减少服务负载。那么，您的数据在UI中会过时吗？你允许那个用例吗？是正确的登录信息过时（一个粗略的例子，我知道，但可能需要解决的东西）

总而言之，这要看情况而定。我认为有些东西非常适合SOA。如果您采取一种方法，那么表示域的服务可能会这样做。通过这种方式，您的UI与域服务对话，而不是表中的行，因为DB被抽象到域服务后面

不要使用一种方法来解决所有问题。

我也看到了

我只想说“有了SOA，我们是为了改变而构建的，而有了传统的系统工程，我们是为了稳定而构建的。”

当然，稳定性的问题是，它只影响到业务的发展——如果组织需要业务敏捷性，那么他们最好实现SOA

所以，这完全取决于你想要实现什么，你是应该划定界限的人

几天前，我在一篇关于SOA的文章中读到了这篇文章，因为我太专注于SOA了

---

编辑：

同时，我看到了这篇文章，并想和你们分享。

---

这段视频很好地解释了SOA的当前场景以及不同的人对它的看法。

它是一个面向服务的体系结构，而不是服务独占的体系结构

表示逻辑和管道必须住在某个地方；这完全取决于它在哪里生活最有意义

例如，假设您有一个UI组件，它依赖于对数据库的一组高度健谈但高效的调用来生成对某些内容的复杂分析（请随意选择）。如果您的web浏览器正在进行所有这些调用，则会带来巨大的网络延迟和并发问题。如果一个web服务进行了所有这些调用，那么您就有可能将表示逻辑放入其中以格式化结果

如果您使用的是会话状态（或web服务周期），那么实际上您使用的是ASP.Net。尝试卸载它，看看您的web服务是否仍在运行

如果表示逻辑需要存在于服务器端，最好是存在于一个用于表示的框架中，而不是一个web服务，IMO。如果您没有看过MVC2，那么就这样做。它使建立一个融合浏览器和服务器UI支持的应用程序变得非常容易（例如，由服务器端验证支持的jQuery验证程序控件）

---

相反，web浏览器提供了一个表达平台。假设浏览器支持和团队知识，您描述的AJAX/SOA体系结构是一个很好的体系结构。我正在越来越多地使用它，并试图使我的服务器页面更干净、更简单，但我没有计划在短期内将ASP.Net从我的工具包中排除。

客户端实现应该与SOA中的后端web服务完全断开连接。该服务应该能够被任何客户端使用。如果您在后端和前端使用.NET，因为它们可以被编码为直接通信，那么您就没有抓住要点，因为现在它们是紧密耦合的，您现在拥有的是一个炉管应用程序。客户机应该不知道服务器端是如何实现的——不管后端web服务是使用.NET、Java还是其他什么构建的

在真正的SOA中，您应该能够在服务存储库中搜索服务，也许可以将输出与其他服务绑定在一起，或者使用XSLT创建在构建原始服务时不必考虑的替代输出，并在前端的任何客户机中以标准方式使用它

---

听起来你真正想问的是如何构建一个应用程序。SOA的要点是通过可重用接口提供标准数据集，这些接口没有考虑到特定的应用程序或实现。首先构建一个应用程序，整个后端由SOA服务组成，这将是一项巨大的任务。在我看来，每个后端服务都应该构建，因为它本身具有内在价值，并且应该提供给整个SOA“域”。然后，当您或我决定创建一个执行X、Y和Z的客户机时，我们可以在SOA中找到这些功能并将其输入测试。

您可以查找首字母缩写，看看您是否同意它的实际含义。把它来回弹一弹，看看除了这三个字母外，还有没有什么真正的想法冒出来。然后做对你们双方都有意义的事。如果你的同事一直在写这些信，那就另找一封。