我在工作中编写的几乎所有应用程序都从中央MSSQL数据库获取数据。这个数据库大约有70个表，平均每个表大约有25列。这个数据库已经发展了5-10年（我不完全确定），充满了特质和怪癖。在命名等方面，以及在表和列名中混合大小写和语言时，外键是不规则实现的。
我无法重组数据库本身，因为它会破坏大多数办公室人员日常工作中所需应用程序的大量向后兼容性。
我几乎只使用LINQ2SQL与数据库交互，它运行良好，但总是需要大量手动连接表，无论是在数据库存储库中还是在编码时"内联"。所以我终于决定，我必须做点什么，一劳永逸地减轻与这个庞然大物一起工作的痛苦。这最好包括实现一个清晰的命名方案，一次性将相关表与外键正确连接等。
我能看到的三条路线是：
-
在SQL中创建许多视图、存储过程和函数，以简化我与数据库的交互。与用C#实现的解决方案相比，这显然具有在许多语言中可用的好处。我在这里看到的最大缺点是，正确地完成这项工作可能需要很多时间，而且在一年后，当我有一段时间没有查看SQL查询时，服务会有点困难。我还需要在我的应用程序中实现另一个DB抽象步骤，因为我不想只使用直接的DB调用（在这种情况下，一个接一个的抽象似乎很糟糕，但也许我错了？）
-
继续我的LINQ2SQL之路，但创建了一个一劳永逸的存储库类，该类仅在抽象调用中隐藏所有底层表。从开发时间、维护和单点抽象的角度来看，这个想法似乎更可行。
-
实现了一些EF4反向工程的魔力，使用设计器连接相关的外键，并根据我的喜好重命名表类。
任何关于如何做到这一点的意见，以及你可能拥有的任何推荐读物，都将不胜感激。
我们的数据库也有类似的情况。我们走的是EF路线，但我们使用的是Code First。我知道在数据库已经存在的情况下使用"代码优先"听起来很奇怪，但由于表的大小和表的数量，尝试在设计器中完成这一切是不可行的。
您可以使用Entity Framework Power Tools中的"逆向工程代码优先"选项从数据库中生成所需的一切。
我认为，如果不是基于数据库的物理模式，经过深思熟虑的抽象层更适合应用程序的需求。我的意思是，DAL的主要目标是向用户隐藏表，通过存储过程只留给他们有效的"活动"。在大多数情况下，这将优于直接数据访问，并为您提供了更多的自由度——在不需要更改应用程序的情况下使用TSQL代码并实现额外的逻辑/模式更改。