使用 LINQ to SQL，其中数据库表可以有额外的列
我们的开发团队希望在数据访问层中使用 LINQ to SQL。我们遇到的一个问题是，我们正在访问的 SQL Server 数据库有时可能在某些表中包含附加列。这种变化是有限的，因此我们最多需要考虑 5 个额外的可选列。
我们意识到我们可以创建 5 个数据上下文，一个用于存在可选列的每种情况，以及一个使用正确数据上下文的开关。但这似乎有点沉重。
有谁知道我们可以继续使用 LINQ to SQL 的方法，但具有一定的可扩展性，以便我们可以使用一个数据上下文而不是 5 个？
注意：我们无法控制数据库架构，因为它属于第三方所有。否则，我们总是在这些表中包含额外的列。
Our development team would like to use LINQ to SQL in our data access layer. An issue we've run into is that the SQL Server database we're accessing can sometimes have additional columns in certain tables. This variation is limited so that at most we need to account for 5 additional, optional columns.
We realized we could create 5 datacontexts, one for each situation where an optional column is present, and a switch to utilize the correct one. But this seemed a bit heavy.
Does anyone know of a way we can continue to use LINQ to SQL, but with some extensibility so that we can use one datacontext instead of 5?
Note: We cannot control the database schema as it is owned by a third party. Otherwise, we'd always include the extra columns in those tables.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们的开发团队认为这不能很好地与 LINQ 配合使用。因此，我们改用 ADO.NET SqlCommands，编写我们自己的 SQL，而不是让 LINQ 生成它。这使我们能够在存在额外列时灵活地更改 SQL，同时保留单个数据层类而不是五个。
Our development team decided this wasn't going to work very well with LINQ. So we used ADO.NET SqlCommands instead, writing our own SQL instead of having LINQ generate it. This allowed us the flexibility of changing the SQL when the extra columns were present while retaining a single data layer class instead of five.