Linq-to-Sql vs CRUD对象？

Question

我有一个表中的linq-to-sql对象。我想在配置文件集合中存储类似的数据。从技术上讲，我不需要linq2sql表中的所有数据，也不需要传统的命名结构。我的第一个想法是创建一个CRUD对象的集合。

但是，如果我选择这个解决方案，我会将具有更多重叠功能的类加倍。如果我按原样使用linq2sql对象，那么我将处理包含更多数据的抽象。

为了给你一个更清晰的例子，我将创建一个类似的例子：

这将进入数据库并创建linq-2-sql抽象

NoteSaved
Date
Id
UserId
Text
....
Custom Methods

这会进入用户个人资料

[Serializable]
SavedSearchText
Text 
...
Custom Methods

SavedSearchText不需要像id，userid和date这样的垃圾，而且这些数据甚至都没有意义。但是这两个类的自定义功能都会重叠。

我看到了两个微不足道的方法：

1. 为此目的创建了一组全新的CRUD对象
2. 使用linq2sql对象作为CRUD的代理，即使用我的“智慧”，这些对象实际上不是“那些对象”

我走的是1路，但看到了很多重复。它不是很干。有哪些解决方案可以保持干净，同时保持清晰的架构？换句话说，我想避免为每个对象复制相同的方法，并且我希望避免将不需要的数据存储到配置文件中，例如不需要的Ids或DateStored。

我认为这应该是显而易见的，但SavedSearchText和SearchText共享一个公共数据字段文本和通用功能，即SomeFunction1，SomeFunction2，即FindText。

编辑/更新：

通常这将通过继承来处理。我们有一个基础业务类Text，然后是2个派生类型SavedText和UserText。但是，使用linq2sql，我没有办法按照DRY原则这样做。

有人也可能选择通过has-a关系来解决遏制问题，但对于这种情况来说，这并不是“正确”。

显然，人们可以创建自己的业务层，但也不会干，因为linq2sql已经具备了许多功能。

也许最干净的解决方案是创建CRUD对象，但只能读取/转储回linq2sql对象。不幸的是，这些linq2sql对象实际上不是“表”，有些字段没有意义。这似乎是最干的解决方案。

在这种情况下甚至可能使用高级方法，例如扩展方法，这些方法可以扩展两个类，但除非需要，否则我不想使用扩展方法。