管理LINQ to SQL .dbml模型的复杂性 [英] Managing LINQ to SQL .dbml model complexity

问题描述

此问题在上得到了一定程度的解决. LINQ to SQL .dbml最佳实践，但是我不确定如何添加到问题中.

This question is addressed to a degree in this question on LINQ to SQL .dbml best practices, but I am not sure how to add to a question.

我们的一个应用程序使用LINQ to SQL，并且对于整个数据库，我们目前只有一个.dbml文件，这变得越来越难以管理.我们正在考虑将其重构为单独的文件，这些文件具有更多的模块/功能特定性，但是一个问题是，许多高级类必须在多个.dbml文件中重复，因为无法跨多个关联使用. dbml文件(据我所知)，以及其他部分类代码.

One of our applications uses LINQ to SQL and we have currently have one .dbml file for the entire database which is becoming difficult to manage. We are looking at refactoring it a bit into separate files that are more module/functionality specific, but one problem is that many of the high level classes would have to be duplicated in several .dbml files as the associations can't be used across .dbml files (as far as I know), with the additional partial class code as well.

有人解决过这个问题吗?您会提出什么建议?

Has anyone grappled with this problem and what recommendations would you make?

推荐答案

利用名称空间设置.通过单击ORM的空白，可以在属性中找到它.

Take advantage of the namespace settings. You can get to it in properties from clicking in the white space of the ORM.

这使我可以拥有一个用户表和一个用于一组业务规则的User类，以及另一个(但数据存储相同)用户表和一个用于另一组业务规则的User类.

This allows me to have a Users table and a User class for one set of business rules and a second (but the same data store) Users table and a User class for another set of business rules.

或者，分解库，这也应具有根据公司的命名约定更改命名空间的作用.我从来没有在需要访问每个表的企业级应用程序上工作.

Or, break up the library, which should also have the affect of changing the namespacing depending on your company's naming conventions. I've never worked on an enterprise app where I needed access to every single table.

这篇关于管理LINQ to SQL .dbml模型的复杂性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！