c# - Dependency Inject Serialization Type -

i have been trying make application configurable possible.

i using unity container , trying use interfaces everything.

at point in application need serialize dtos xml , xml using dataaccess layer.

however, had thought in mind. why should xml? shouldn't can configured in container? serialization type or that?

i understand there xmlattributes can used tightly coupling serialization xml. thinking of using iserializable noticed ixmlserializable not implement iserializable.

so know how use interface / base / abstract class allow configurable serialization can configured through di container?

theoretically think outputformat-agnostic attributes possible, although depends on how (dis)similar output formats want support. example, xml , json both use field names json doesn't have distinction between attributes , elements xml has. binary serialization on other hand has no use field names because information stored positional.

to honest though, i've never seen such implementation.

what have seen happen define 2 "schemas":

• one entity classes defined in storage-agnostic way , designed easy handle in business logic (i.e. calculated properties, inheritance, , whatever else might you).
• and set of classes designed solely serialized 1 specific output format. xml mean using [xmlattribute]s, storage in database using [primarykey] attributes, having data of 1 logical entity spread on multiple entities because database stores data more normalized.

serializing storage-agnostic entities comes down first mapping them storage-specific types, , serializing these types. mapping code can written hand, or done automapper.

the key here rather using 1 set of attributes try cover serialization needs, more feasible create complete new set of entities designed serialized 1 format.

---

as aside, if may give unsolicited advice: have yet see application needed serialization format pluggable. mean, understand need separation of concerns, , "the rest of application shouldn't bothered knowing this-or-that", @ point have make some decisions such things in database data stored, or kind of webservice api application provide.
deferring these decisions or trying hard abstract them away hurt how understandable code looks , how easy add new features it.

there fine line between "separation of concerns" on 1 side, , "making possible swap 1 database engine another" on other side. true when have separation of concerns easier change type of database you're using, (in opinion) being able swap database types should consequence, not goal on own.

to take point question: don't think bad if takes more effort reconfiguring di container change way serializes entities - changing never happens in reality anyway.
long keep knowledge serialization confined specific part of application, don't have plough through all code when do have change :)