23 September 2013
Document generation functionality can be seen as separate UI layer in an application and could have its own "view models". In your case this means that your EF entities are models that would be the source for your "document generation view models". Creating another tier of data objects (VM) has the same reason as creating them for rendering Views. Your models simply do not always have all the properties ready for data binding and this is why you need a specially shaped data objects are suitable for data-binding in Views. On the other side creating another set/layer of such objects (including mappings) is (I think) mostly seen as overhead and people rather use their Data Access (EF) objects directly by extending them with calculated properties or handling the
Yes, another option is to use XML. Here are the summarized differences:
- XML: If your data is represented by .NET objects than there is additional effort and complexity to convert them into XML. On the other side, the binding language (when editing templates) is XPath which means that you can write complex XPath expressions if you want and this way achieve data shaping directly in templates.
- .NET Objects: You can mostly use your existing DTOs/busines objects/entities as data sources directly. But the binding language is only limited to memer (property or field) selection and there is no way to do data shaping inside templates. To compensate this inability you have to resort to class extensions, creation of specific set of classes or handling the
- DTS Objects: Same pros and cons as .NET objects except they are more simple than .NET objects.
I mostly prefer .NET objects (or even DTS objects) over XML because:
- there usually already are existing .NET objects to use or they can easily be created using your favorite language (C#, VB.NET)
- .NET schema has cleaner semantics than XML schema for distinguishing between single objects/values and collections - which is vary important when creating templates.
Last edited 04 October 2013