SOA的困惑

     最近项目里需要兼写一些Asp.NET的管理后台，才发现自己有一段时间没有碰过Asp.NET的开发了。前一段时间一直在做BizTalk的项目和开发，做起来有些手生。不过今天要谈的不是Asp.NET Coding的问题。而讨论一下在Asp.NET开发过程中的一些应用“SOA”思想的困惑。

     开发BizTalk的时候一般的场景是各个应用系统已经将服务定义和发布好了。不管是以什么形式提供的，也不管是什么接口类型的。由于BizTalk支持多种协议和以XML Schema为基础的消息架构。因此可以轻而易举的将消息在不同的系统之间做路由和映射。带着这种思想我也在管理后台里应用了"SOA"起来。其实这个管理后台是很典型的几个表的数据库操作。例如我们有A,B,C三个表，其中C表与B表外键关联，B表与A表外键关联。对A表的操作是直接添加记录即可。对表B的操作是要将表A的主键ID与B的数据一起写到表B中。对表C的操作主要是将表B中的主键ID与C的数据一起写入表C中。

      好的我们大概知道了对数据库表的操作。由于项目需求不明确，还不知道用户是希望使用C/S还是B/S来访问管理后台。所以我的想法是应用“SOA”的思想将数据库的操作通过Web Service的方式暴露出来。供前端的Winform或者Web Application来访问。由于后台比较简单我就使用代码生成器生成了对这些表的操作代码。并且通过Web Service将这些接口（比如每个表的查询、添加、删除、修改操作）暴露出来。这样一来我们就可以看到这个管理后台的一些功能了。由于第一阶段需要给客户演示，时间比较紧，我就使用soapUI来调用Web Service。主要的目的是让客户看到管理后台的功能和操作。通过在soapUI中来回拷贝和粘贴ID与其他数值，成功实现了对表的操作。由于使用这种方法在开发上节省了一些时间使我当时感觉到了应用“SOA”思想的甜头。同时也觉得我直接在这个基础上再加一层Web 控制页面就可以了。

      客户在看了演示之后对管理后台的功能比较认可，但由于soapUI毕竟不适合于用户的使用，所以客户希望能够开发一个Asp.NET的Web Application来提供给用户操作。有了前面的基础我觉得开发应该快就可以完成了。但是实际做的过程中我才发现"SOA"把我整得很恼火。由于前期开放的Web Service只有查询，添加，删除，修改四个单表的操作。但在做Web 开发的时候需要考虑到用户的体验，比如在显示C表数据的时候为了给客户直观的效果我们要显示表B与表A的相应记录的名称而不是ID，还有我们在往C表里插入数据的时候我们还要提供可以供用户选择的A表与B表的数据。那这样一来我还得花时间去完善之前发布出来的Web Service方法以及操作数据库的SQL语句等。由于在开发过程中是采用前端往后端推的过程所以造成了代码没有进行很好的规划经常会出现“补了西墙，拆了东墙”的情况。还有由于Web Service与Web Application不在一个项目，不在一台机器上所以Web Service的调试也给开发带来了一定的麻烦。

     最后，通过整理了一下思路。决定不采用Web Service层了。直接Web层就连接数据库操作层。而且把原来的项目合并在一个解决方案里。很快就把这个管理后台给开发出来了。

     虽然程序已经开发完成了，但我还是有一些困惑没有明白。本来在程序中应用Web Service层是为了可以支持多种的前端技术。并且在前期使用soapUI来POST数据的时候确实节省了一部分的开发时间。但是在后期当客户需求有变动的时候Web Service却给开发带来了麻烦。个人感觉问题应该是出自于对接口的设计方面，前期的时候由于soapUI直接调用接口和专业人员的操作，基本的数据库的操作方法就可以满足需求了，因此开发很快。但是接口没有考虑到用户的体验所以没有暴露出相应的接口或者暴露的方法提供的数据不能满足需求。因此靠在实际的开发过程中使用反向的往上面一层去构造方法。给开发带来了很大的麻烦。

    可见不同的需求对于希望暴露的接口和得到的数据是不同的。由于在这个开发过程中我可以通过创建或修改方法来满足我的需求。但是复杂系统的SOA又应该如何设计各系统接口和提供的信息以满足不同的业务需求呢？我们知道在SOA思想里服务是一种高级别的封装，我们该如何在整合开始前就把接口设计好，并且如果遇到新的需求的时候我们怎么提供更好的方式可以添加或修改接口?

    当然SOA还有很多不明白有地方，而且也不知道在项目中这样使用是否叫作应用"SOA"。虚心听大家的教诲。