数据存储的算法 --------------求救

Question

在没事的时候自己很喜欢去看看以前写的代码，最近在看到对多表插入的数据的时候有了点疑惑，特拿出来让大家帮我分析一下。现在有3张数据表，分别是：A,B,C
业务规则是：这3张表彼此之间是有关联的。在进行存储的时候，需要先对A表进行插入，如果成功那么就返回A.ID;然后把A.ID插入到B表的AID字段中，然后对B表进行插入操作，如果B插入成功就把返回的B.ID插入到C中的C.BID；然后对C表进行插入操作，如果成功就把把这个事务COMMITE,否则ROLLBACK.我 以前的处理方法时候通过传递一个事务参数，给执行插入操作的方法，这样就保证他们是在同一个事务进行。那样做也有个弊端就是让数据层保露给页面层。
现在我有个想法就是：是否可以在页面只把要输入的数据传递给一个List<>，那样我就可以把事务在底层进行封装。如果成功的时候我就返回一个DataSet,里面包含刚才插入到表的数据记录。
现在的遇到的困难就是：在页面层他们怎么建立主键和外键的关系？有怎么传递给数据 处理层那？数据层又怎么来对传递过来的List<>进行分解那？
希望各位达人进行解决一下！！！！！

Answer 1

你做了任何事都可以用“让它不暴露”作为理由来随便否定，然后只能到“什么也做不了”的结果。“是否可以在页面只把要输入的数据传递给一个List<>”其实可以说成是“是否可以在页面只把要输入的数据传递给一个!@#$%^&*”或者任何符号，根本出发点是一样的，只要把接口混淆成一团糨子，就能成为万能的功能了。你的问题根本没有你那种路子的答案。我给你说明一个真正的“不暴露数据层”的概念：就是当你知道多种数据层接口之后，你可以将它们抽象成通用的接口，并且当你将整个系统切换到别的系统上的时候可以用“一句话”来完成，例如仅修改.cctor中的一条代码或者修改web.config中的一个参数。把“不暴露”说成是“根本在概念上不接触”，这确实过分、童话地去理解技术了。如果你对A的业务的定义只能达到“进行存储”的地步，那么这个“进行存储”就是A这个业务的业务层的操作，如果你把它区分为“订房、退房”两个生活化的操作那么就是另两个业务操作。业务逻辑上的操作深入下去就会到达数据操作、ui操作等等。接下来，如果你觉得A、B、C的三个操作应该在一个实务中，你就应该定义一个实务概念，例如你的事务跑不出System.Transactions.Transaction那么你就可以从这个继承，跑不出System.Data.Common.DbTransaction你就可以从这个继承，或者如果你有那的出手的自己对Transaction的定义就用自己的，让它们的操作中必须作为参数提供或者其他组织方法。总之抽象是一种纵向的一般化/具体化的关系，抽象不是回避。你的问题是在问有没有

Answer 2

本来你的问题很好回答——只要将 Transaction抽象到比较高级的描述就行了。可是你的给出的思路“是否可以在页面只把要输入的数据传递给一个List<>，那样我就可以把事务在底层进行封装”让我感觉到你的做法不是在有条不紊地利用面向对象的一般化/具体化方法建设一个东西，而是在想到哪里敢到哪里遇到挫折就回到起点重新再撞。