这更多的是一种哲学/最佳实践排序问题而不是技术问题。
是否有反对与写作是方法DataContract类中的任何有力的论据，以仅用于服务器端？ 或者有什么有关未装饰的数据成员属性的附加属性？
例如：
[DataContract]
public class LogEntry
{
[DataMember]
public string Message { get; set; }
[DataMember]
public string Severity { get; set; }
public string SomeOtherProperty { get; set; }
...
public void WriteToDatabase()
{
...
}
}
如果不这样做，似乎像一个可怕的很多，我宁愿避免额外的工作，虽然使用扩展方法可以更容易。 但是，作为一个优秀的开发人员，我想知道，如果它是不好的做法，这样做。
从技术上讲，你可以在数据合同同一类添加实现。 只有那些由于性能会得到序列化。
在你的榜样，你有对象，运输以及如何编写在同一类数据库：
[DataContract]
public class LogEntry
{
...
public void WriteToDatabase()
我会建议您的前端代码和对象是那些获得序列是从持久性分开。 我甚至会建议不具有层或者其自己的运输和业务逻辑之上的层的责任，知识一个单独的数据库访问层。
如果数据库持久性数据中的合同和传输层，随着时间的推移，这将是不可能梳理出，如果你需要更换层 - 这将是一个代码斑点。
分离层也有助于测试。 能够测试的代码单元没有一个完整的系统的所有依存关系是有价值的。 例如，如果您将您的数据库持久性，甚至与界面分离的，单元测试你的业务逻辑，你可以更换一个子集在内存中执行的持久性。
其中一个问题就变成了如何通过这些对象下到DAL如果它没有是那些获得运输对象的知识。 要强制执行的分离，我见过一个类型的dll它只是包含了数据契约的装饰，拥有运输和BLL / DAL这两种引用类型的dll服务层这些结构。
希望帮助。
你当然可以添加任何你想要的类型，因为只要WCF而言，只有那些明确选择加入作为承包商，客人DataMembers是合同的组成部分，将被序列化为这样。
我认为它是清洁不把多余的成员订立合同的，可以在您使用的类型是混乱的。
其实，这真的取决于上下文
通过上下文我的意思是：一是项目管理方面：资金预算/时间/ developpers水平/预期寿命的项目，然后WCF上下文的时间：它是一个Web服务（WSDL）或namedpipe转移
如果你是短的一切，你不希望任何人比你深化发展，以连接到Web服务客户端，你觉得舒适的使用这种方法去做。
在所有其他情况下，我会建议，以便仅从实现细节分割协定代码。
请注意，在WCF namedpipe情况下，你可能有意只实现一次由客户端和服务器共享的组件合同。 在这种情况下，你的风险暴露给服务器的客户端签名。
