Your mapping to your database is generally coupled to the design of the data and the mapping provider’s ability to implement a relational or non-relational model. This means your ORM influences the design of your mapped classes and/or the design of system that uses these mapped classes. i.e. your design can be limited in certain aspects by how the mapper is implemented. Because of these idiosyncrasies, your choice of ORM becomes an implementation detail; so, you want to keep any of its details and generated classes out of your interfaces. You want to keep your ORM’s classes and the classes … Continue reading Mapping to Your Database is a Private Affair
WCF service define “data contracts” for their interfaces. These contracts are often defined in an XML schema document and used to generated WCF data contract code. This process effectively creates a .NET type that will serialize to a chunk of XML text. Depending on the operation of the WCF service, its code may be responsible for creating some of these objects. A return value from an operation, for example. While the framework handles XML serialization of these object behind the scenes. But, if your have complex types and you end up not setting all the properties correctly in your object … Continue reading Unit testing WCF data contract serialization.
With WCF services you need to declare contracts and generate contract classes that encapsulate those contracts. Most of the time you can simply let the framework deal with whatever it needs to do to deal with these objects. Sometimes, you need to actually see without running a service what XML would result from a contract object or serialize a contract object from XML text. In .NET 3.5 there exists the System.Runtime.Serialization.DataContractSerializer class that perform serialization of data contracts. Based on its documentation it seems fairly simple to create data contract object to/from XML methods. For example: public static T … Continue reading DataContractSerializer.ReadObject is easily confused.