实现该设计的障碍

    在转向这种统一的设计的过程中，除了编码方式的改变，还有几种困难。

    习惯

    俗话说："江山易改，本性难移。"在团队中也是如此。在一个团队里你不仅要说服你自己，还要说服你的队员。

    流程

    许多公司的安全策略规定必须在数据库中对安全进行控制，而使用存储过程无法提供足够的控制。让公司的安全策略转向中间级是一件相当困难的事。

    虽然随着.NET等的发展展人们越来越关注中间级的安全性，但是许多企业仍然把重点放在数据库上。

    数据库管理员

    这可能是一个敏感话题。但是不管如何，我们必须提到这一点。不管是你是一名DBA或是一名开发人员，请别把我说的话当作真理应用到所有的DBA身上。如果你是一个没有这种困惑的DBA，那么恭喜你！你是数据库的领导者而不是守旧派。

    通常DBA不愿意做出任何实质性的改变，因为这会打断他们现有的系统。许多企业都有一名DBA和许多DA（数据库助理，Database Assistants）。DBA就是这个领域的头儿。只是管理部门才能影响到DBA，而管理部门在DB方面上的失误通常会归咎于DBA。

    大部分DBA对n级系统了解甚少，甚至根本不关心。对于他们来说，任何级都只是一个客户端，所有的东西都只是一种客户服务器模型。他们只关心他们的服务器，只要不会造成什么严重后果，他们拒绝向开发人员做出任何妥协。

    DBA不像开发人员流动性强，他们通常都在同一公司里呆了10年甚至20年。数据库就是他们最重要的东西，他们不想做出任何改变。他们有自己的王国，并拒绝交出任何控制权。让这样的DBA放手一部分安全和实现通常需要极大的努力以及管理部门的参与。

    也有部分DBA没有这么固执，他们会接受任何合理的东西。但是在许多企业里，特别是大型企业里，DBA通常都坐在企业指挥系统的最上层。

    工具

    当前的大部分工具都无助于业务逻辑的实现。它们只是用于提高扩展性、连接池等并且无法满足业务逻辑实现的需求。

    实现设计的解决方案

    架构监控

    让系统架构设计人员经常性地对业务逻辑进行审查并标记不妥之处是一种很有效的作法。发现得越早，执行起来就越容易，也更节省修复的成本。如果你不想指定一个专门的架构负责人，那么开发人员可以互相进行监控。如果有人发现不妥，他就会通知团队。

    培养DA

    DA的培养非常重要。他们长期进行着业务逻辑的实现，因此可能很难区分业务逻辑与存储。DA通常只是根据DBA的命令做自己的任务。

    DA的职位仍然存在。他们不仅要继续做自己的工作，还要监控来自中间级的SQL和数据库性能。他们还要继续做数据库设计。

    管理层

    通常管理部门对此会比较抵触，但是相对来说这还是一个比较简单的障碍。虽然他们不关心你的工作是否会变得简单，但是他们关心成本。

    与此相关的主要障碍应该是来自DBA。所以要说服管理层，让他们处理DBA的问题。

    其他

    本文提到的方式我已经应用近十年。当然在此过程中我也做了许多修改。

    总结

    改变企业的方向是一项冒险的决定。开发人员应该采取低姿态，让其他人做主要工作。许多开发人员会彻底改变他们习以为常的习惯。我希望本文能帮你改善当前的过程，或者至少能帮你做出更有价值的决定。

    本文所描述的方法最适应于新系统、或者重建的完整系统、或者重建的部分系统。对于既有系统，最好还是先保持现状，直到产生其它需要对其进行重新设计的更为重要的原因。