Question

已经查看了其他问题，但看不清楚答案。

我们是一个小型开发团队，致力于可以被描述为3个独立的前台“应用程序”（通过asp web的OnlineOrders，TradeManagement winforms app，ASP.NET ReportingSuite）。

然而无论好坏，每个应用程序共享一个中央SQL2005数据库，我们称之为MainDB。它们都使用相同的Orders表结构，用户，帐户等，每个应用程序都以某种方式使用了大约80％的对象。

在TFS中，我曾认为这三个应用程序中的每一个都是独立的项目，包括工作项跟踪，报告等等。似乎工作正常，我们的“基于代码”的解决方案已经创建。

现在，我正在尝试了解如何将MainDB数据库导入TFS源代码管理。我看不出一个明显的方法来做到这一点。

问题：我是否应该为MainDB创建一个数据库项目，将模式导出到项目中的脚本中，并将该数据库项目添加到每个TFS项目中的每个解决方案中？

或者我应该为我的数据库项目单独设置一个TFS项目？开发人员必须打开MainDB数据库TFS项目和（例如）TradeManagement TFS项目开放以开发新功能（因为大多数新功能也会涉及一些数据库更改）？似乎非常沉重。

或者只是拥有一个名为“Everything”的大型TFS项目，并且其中包含代码项目的功能分支，数据库的数据库分支以及可能使用MainDB数据库的任何其他项目？（在img中，假设MainDB脚本位于'Database'文件夹中）

alt text

等。伙计，我很困惑。 Codeplex似乎指出通过将所有解决方案放在大单解决方案中来保持简单。这可持续吗？

感谢您的回复，非常棒。

将数据库视为API的想法很有意思，就是这样。数据库来自众多来源，一些内部，一些外部，一些应用程序获取通过另一个应用程序输入的数据。将其作为每个应用程序进出的API控制是一个非常有用的类比，谢谢你。

不支持依赖关系的成本是一个问题，但我认为我们可以足够自律地以有序的方式进行分支。应用程序代码库的分支可能比数据库更复杂 - 我们真的只是希望源代码控制下的数据库以某种方式满足Sarbannes-Oxley审计要求。

我将不得不考虑更多。

db的水平分区不是我考虑过的。感觉有太多的数据库对象被共享以便能够将它切成水平块 - 我们在几个块中有相同的对象（表/ sprocs等），我认为这会让我们更加困惑。

Answer 1

对于仍然对我们最终如何做到这一点感兴趣的人：有一位TFS专家帮忙！

我们为此付出了沉重的代价：将所有解决方案拆分到他们的项目中，将所有项目放入相关的存储桶中，在源目录中包含.sln文件，以便于查找。这是组织事物的合理方式，并且到目前为止已经发挥作用。

<Branch>
Source
    Solution files at root
    Server Apps     Previously “services”, helper apps running on server
        App 1
            Project 1
            Project N
            Installer
        App 2
    Services    WCF/Web services providing business operations
        App 1
            Project 1
            Installer
    Client      Rich client applications, e.g. WinForms, WPF
        App 1   
            Project 1
            Installer
    Web     Server side web applications
        App 1
            Project 1
            Installer
    Database    All scripts related to database structures and data
        Databases
            SMOL
            AuditAuthentication
            …
        Servers (Environments?)
            Server1.proj
            Server2.proj
    Common  Reusable classes across applications
        Communications
        Security
        ….
    SharedBin   3rd party binaries
        EnterpriseLibrary
        …
Docs
    Release notes
    Help files
Scripts
    Deployment
    Data Migration
    …
System Tests
    Functional
    Performance
    Security
    …

这就是VS中的样子（保护无辜者的一些混淆）

Answer 2

在这种情况下，我将数据库项目放入单独的项目中，并从其他项目中引用它。

恕我直言，如果您的数据库（单个数据库实例或只是公共数据库模式）在多个项目之间共享，那么您需要将数据库模式（或至少其中的大部分）视为暴露给这些项目的接口。此接口/ API需要对任何单个项目进行独立的变更控制和版本控制。因此，数据库成为所有这些项目的外部依赖，就像任何共享库或服务器一样。

现在。您正在使用TFS。在TFS中有单独项目的成本。 TFS的分支模型基于具有项目树的单一命名空间。这需要很多关心和纪律，否则你会搞乱合并等。

此外，完全缺乏对项目之间依赖关系的支持。如果您想要更改控制项目之间的依赖关系，您必须将项目分支为依赖项目的子项目（具有上面提到的所有分支和合并跟踪问题），或者教您的构建系统始终从TFS获取正确的版本（我觉得很可怕）。

请注意，如果需要单独发布/版本化每个部分，项目“Everything”将无济于事。你提到了子项目等的“特征分支”。它将比单独的项目更糟糕，至少是明确的。如果您都公开同意维护通用数据库项目，那么当您发现需要在所有其他项目团队中协商每项更改时，就不会感到惊讶。

所以，最后，这是你的决定。涉及的所有项目是否足够单独，以便将它们作为单独的项目进行版本化。他们是否会分歧？你希望或需要他们分开吗？是否值得花费额外的工作费用？

并且完全不同。您所谈论的只是将代码库垂直划分为多个层 - 这里是数据库项目（带有数据库架构等），这里是数据访问，这里是业务逻辑等等。

您是否考虑过横向划分为域级别块，每个块都已完成并由其数据库架构进行备份。您的项目不仅取决于通用数据库架构，还取决于一个或多个共享模块。每个人都会带来自己的数据库脚本。

我只是在想这里。我不确定这是否会更好，或者它是否会在实践中发挥作用。任何人都可以分享他或她的意见吗？

我应该将数据库项目放在TFS中的哪个位置？

3 个答案: