c# - future 证明DAL

我们正处于一个非常漫长的开发项目的开始，该项目包含多个子项目。基本上，每个子项目都将花费几个月的时间来开发。该代码本身将拆分为多个C#项目，但是物理数据库将由所有项目共享。

问题是可维护性。如果我们在表中添加一列，或将一个表拆分为两个较小的表，则必须返回并修改C#DAL以支持这些更改。这是 Not Acceptable ，因为我们将不断使数据库适应整个公司的需求，而不仅仅是单个程序的需求。不断更改旧代码将是一项永无止境的任务。

我们的数据库人员提出了不同的看法。我们通过存储过程进行所有CRUD，并在多个表中使用Linq来执行SELECT语句。然后，如果我们从现在开始对数据库进行重组，则可以简单地提供相同的存储过程和 View ，而不必修改我们的旧代码。

我们的问题是，对于这样的事情，应该使用什么ORM？ EF似乎有点矫kill过正(也许不是)。带有SubTonic的T4模板之类的东西会允许使用仿真器(也许更快)的DAL吗？

也许有人对如何减轻整个过程的痛苦有一个想法？我们不想在应用程序中添加另一层，但是我们也不希望每次进行数据库更改时都返回并修改代码。

编辑1:
因此，当我说“我真的不想添加更多的图层”时。这主要是因为我们已经有几层了。我们有Silverlight View ， View 模型，BLL对象(通过CSLA)，然后有DAL，最后是SQL表。

最佳答案

C# DAL... not just the needs of a single program。 C#DAL作为单独的程序集的全部要点是，它可以在任何类型的.NET应用程序中重用。您将遇到的主要问题是，如果数据库发生更改，则DAL必须更改一次，然后所有依赖DAL的应用程序都必须重新部署新的DAL。您还会遇到非.NET应用程序不能使用DAL的问题。

好的，那么如何集中DAL，而不必为每个应用程序重新部署DAL？想想SOA。您可以构建WCF服务以包含DAL(可能还有BLL)。您的所有应用程序(如果使用Web服务，即使不是.NET的应用程序)都可以使用此服务。当数据库更改时，您将更新WCF服务并部署一次。只要确保您没有进行任何重大更改即可!如果需要添加/更改功能，请创建一个MyMethod2。


We'd rather not add another layer to our application。好的，所以三层架构可能不是您所需要的最佳方法。
neither do we want to go back and modify code everytime we make a db change然后，您的DBA人员提出的建议是唯一的方法。

但是，请考虑以下问题:更改存储过程是否与修改代码相同？基本上是同一回事。 SQL存储过程通常不受版本控制或测试，但是应该。 SQL没有像.NET这样的语言丰富。 WCF可以轻松地在Web场中进行扩展。一旦考虑了这些和其他原因，就值得采用三层/SOA方法。

这实际上取决于项目的规模，员工的技能， future 的成长等，而这只有您可以确定。

关于c# - future 证明DAL，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4729580/