强化数据访问层

情况：dba是一个异地承包商，将整个DAL代码保留在TFS中。作为前端开发人员，能够添加列，调整proc和诸如此类的东西，而不必依赖于等待该家伙响应您的电子邮件来完成工作，那将是很好的。

问题：什么是建议的解决方案/过程，以允许更快，更敏捷的开发，同时保持数据完整性以及团队之间的和平爱与幸福？

马丁·福勒（Martin Fowler）和普拉莫特·萨达拉奇（Pramod Sadalage）就这一主题写了一篇出色的文章。

每个开发人员都有自己的数据库，可以对其进行更改。然后，将这些更改传达给DBA（作为更改集），该DBA在主数据库中实现这些更改，因此他仍然参与该过程，无论如何他可能最了解数据库的结构和需求。我认为这是最好的方法，因为它使参与此过程的所有人员都感到满意，而且它也非常灵活。

您可以以类似方式更改DAL。只需进行更改并在您认为完成后为DBA提供一个变更集，以便他可以对其进行检查并将其合并到他的母版中。

Wellll，当我做DBA时，众所周知，我会将所有东西都锁起来，这样该死的肮脏的程序员就无法理解。每个人都认为他们知道如何做得更好，并且他们“调整”事物以使其更容易使用，这会造成不洁的混乱。

另一种选择是将其敞开，让程序员在其上混战一会儿，然后随着事情开始接近结束而跳入并强加命令……这当然更“敏捷”，但可以真正的噩梦取决于必须削减或更改的内容。。。DBA通常对整个项目有更好的了解，有些看起来无害的更改可能会带来问题。

如果他将成为唯一的网守，则他需要制定固定的规范，或者能够将其愿景“出售”给其他开发人员。

有一个主要问题取代了其他任何问题：

1. 为什么承包商总是要签出代码？

为什么允许他这样做？除非他们正在积极进行编辑，否则没有人要签出文件。应该有关于结帐的团队政策。

承包商（不管他们是否喜欢）是团队的一部分，有时团队的其他成员可能需要进行更改。这是一个沟通问题。不幸的是，没有自动方法可以解决此通信问题。

我更喜欢在筒仓的跨层工作，而不是水平层。

这样，任何人/团队都无法以这种方式进行封锁。

这也意味着您是开发人员，具有多种技能，能够更轻松地移动功能。

当然，有些部分（UI设计和DB设计）可能需要更多的专业工作，但是您会明白的。

很简单，如果您还没有，那么应该有3种环境：

• 开发环境
• 质量检查环境
• 生产环境

开发环境应由开发人员管理。

您可能还需要添加RC环境。

另一个答案是，如果不可能有多个环境，则可以针对模拟的存储库进行开发...通过这种方式构建模型，然后由承包商负责使模型与数据库匹配。从某种意义上说，这更好，因为它使您的开发人员不必担心数据库。

在我看来，您的问题是人手之一。由数据库专家批准所有潜在的基准数据库更改是适当且必要的。如果当前人员不能及时跟上工作，则需要更多的数据库专家。

与技术问题一样，这是一个管理问题。

DBA（无论在现场还是在外，承包商还是雇员）肯定有正当理由阻止开发人员进行任何类型的数据库更改。

但是，您定义的主要问题是可用性之一。您的经理是否知道浪费时间/金钱在等待这个人上？如果没有，您可能想提起每个人都坐在那里的方式。