none
POCO to Object Mapping C# RRS feed

  • Question

  • I have 3 classes on of which I have control over [Machine - my POCO]. 2 classes are 3rd party;
    Item and ItemValue (which is derived from Item). Item has a property UniqueIdentifier

    I have a server that requires Item[] elements to be passed to it, that are updated by the server.
    The server has a change event that I receive a callback with an argument ItemValue[] items.
    Which items can contain anything that changed - including items not in my POCO.
    I need to easily map the property ItemValue.Value to my POCO properties, so I can set the value of the POCO.
    I am using the POCO to update a dataBase and also to bind to the UI, I have implemented INotifyPropertyChanged
    In this POCO.

    If at all possible I would like to do this all generically if possible ,
    so maybe I need an intermediary like Mapper<T>
    Which I am thinking I can use to Create My items Item[]
    For each Property of T , CreateItem => Item , assigning the UniqueIdentifier, assignTargetAddress, DataType

    Add to a Dictionary of <UniqueIdentifier, propertyName (from type T)

    I am really at a loss as to how in the world to do this. Any help is appreciated.




    public List<Machine> Machines; public List<Item> MachineItems;   public class Machine : IMachine { [DataMember] double SensorA {get; set;}   [DataMember] double SensorB {get; set;}   [DataMember] string Sytem1 {get; set;} } public class ItemValue : Item { object value; } public class Item { object clientID;
    string targetAddress; System.Type sysType; } OnNewlyReadValues(ItemValue[] itemValues) { // each itemValue in itemValues represents a property // in the POCO . // itemValues May contain one itemValue or all itemValue // that represent the values in the POCO. // Determine if itemValue is for which Machine.PropertyName // property SensorA (or any of the properties) // Machine.Property = itemValue.Value; }




    When you think there is no way, there is a loophole. When you have made it idiot proof, they come out with a better idiot.

    Tuesday, May 19, 2015 6:53 PM

Answers

  • A POCO? Maybe a DTO should be used, since its purpose is to pass data between processes, like WCF client to WCF service.

    http://en.wikipedia.org/wiki/Data_transfer_object

    http://www.mindscapehq.com/documentation/lightspeed/Building-Distributed-Applications-/Building-WCF-Services-using-Data-Transfer-Objects

    And the use of 'object' if it is in the Datacontract is proably going to be trouble, since it is not a known type object, and  it is a base object of all .NET objects.

    I have implemented INotifyPropertyChanged In thisPOCO.  -- This may be trouble too if it is being used in the Datacontract as it is going to get fired in the serialization and deserialization process marking the object as dirty erroneously when nothing changed in the object.

    What should be bound to the UI is what I call a SmartDTO that knows that xan set its state, which is based on the principles in the link.

     http://www.dailycoding.com/Posts/maintaining_dirty_and_new_state_of_objects.aspx

    The DTO that you send between the WCF client and service is a dumb DTO that just has all the public properties and private flags in the SmartDTO mapped to public properties in the dumb DTO. The dumb DTO is hust using auto propties like Name String {get; set;}

    You get the dumb DTO back on the WCF service side they you can check it. The dumb DTO is sent form the service to the client where you map it to the SmartDTO and use it at the UI. You can't send the SmartDTO through WCF becase the MarkDirty() fuction will get fired in the serialization process.

    If IsNew and IsDirty = insert into database

    If !IsNew and IsDirty = update existing data in database

    If IsDelete = delete data from database.

    As far as object property mapping, there is AutoMapper, and you can make object mapping as simple or as sophisticated as you like.

    http://www.codeproject.com/Articles/61629/AutoMapper

    I use this stuff all the time in N-tier or when WCF is invloved and data persistance is sitting behind the WCF service.

    Tuesday, May 19, 2015 8:26 PM
  • As I am looking at what a DTO is [https://msdn.microsoft.com/en-us/library/ms978717.aspx] , it appears as if the whole object is passed Get/Set this dumb object pass it from one side to the other and work with it, like a middle man, the real work is done by a smarter object - but the simplistic object is passed. Is that it in a nutshell ? Low overhead , simple object.
    Would this be accurate ?

    The simplistic DTO is passed between the WCF service and client because of the Datacontract XML serlization of the object that is going to firer in the getter and setter if logic is in them. If the setter has the MarkedDirty() method in it, then the IsDrity flag is going to be set to true becuase the object was past between the WCF service and client in either direction and marking the object as dirty when the object should not be dirty.  The only time the object should be marked dirty is becuase of a true interaction of  code setting data in the object's property and not becuase it was sent between the WCF client and service and XML serialization happened on the object on the trip firering the getter and setter.

    Take WCF out of the situation and you were sending SmartDTO(s) up to the UI. The fact that you set data in the object property form the database is going to mark the object as dirty. But before the object is used up at the UI,  which is an old object and existing object from the database, the object must be marked as old Markold(), which is a function in the object from the link about setting the object's state.

    If WCF was not in play, you can just use the SmartDTO all the way. But becuase of the XML serlization taking place with WCF on the object, you can't send the SmartDTO, and you have to send the dumb one that has no logic in it on the getter or setter based on what will heppen if either the getter or setter has logic in them during object serialization.

    Tuesday, May 19, 2015 10:03 PM
  •  

    but perhaps following the employee example you provided - when I set the values of the Client Object the IsDirty flag would be set and the object is updated? [The employee sample looks like a bit more than getter/setter - is that considered a DTO or is that the smart DTO?].

    The Employee example in the link is really about a business object in a Business Layer being used in a n-tier application. I took the concept and applied it to DTO(s) making the DTO set its state when code sets one of its properties with data. - the SmartDTO. The DTO is what is carring the data between the tiers/processes. The fact that the UI code in some way interacted with the  DTO and changed its content sets the DTO state to dirty. The DTO could have had a property changed in the Business Logic Layer,  or the DTO can have its dirty flag set in the DAL by the DAL making a chenge to the DTO.

    But the bottom line is this . Whatever logic is going to take the DTO's data and persist it to the database, the logic needs to kown the state of the DTO.

    Is the DTO's state dirty? If it is,  then the logic is going to do something with the DTO to persist its data to the database.

    If the DTO's state is new and dirty, then the data is going to be inserted into a database table.

    If the DTO's state is not new and dirty, then the logic is going to take the DTO's data and update an existing table record in the database

    If the DTO state is delete, then the logic is going to delete a record from the database.

    If the DTO's state in not dirty or delete, DTO is ignored/bypassed for persistance with the database.

    The only code a SmartDTO has in it is the flags that indicate state and any methods() that deals with the state flags. The concept of a CSLA Business Object is a lot more complaicated than what you are seeing even in the link provided, The simplistic part about the object state was ripped out of the business object and applied to the DTO, which would be DTOEmployee - the SmartDTO. The simplistic part about the object's state is being talked about in the link. 

    The DTO that travles between the WCF client and service adhear to the below principles it is dump object

    http://en.wikipedia.org/wiki/Data_transfer_object 

    <copied>

    The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing

    <end>

    The SmartDTO has behavior/methods the strickly and solely deals iwth the object's state. It has no other logic or behavior   other then object state behavior.

    You can't send the SmartDTO through WCF in either direction, which has been explained as to why you can't send the SmartDTO.

    You have to map data between the SmartDTO and DumbDTO and vice versa.

    Where the concept of an object keeping state is out of the books.

    http://www.barnesandnoble.com/listing/2671620427874?r=1&kpid=2671620427874&cm_mmc=GooglePLA-_-Book_45Up-_-Q000000633-_-2671620427874

    Books are 2003, 2005, 2008 and so on.

    Wednesday, May 20, 2015 6:36 PM

All replies

  • A POCO? Maybe a DTO should be used, since its purpose is to pass data between processes, like WCF client to WCF service.

    http://en.wikipedia.org/wiki/Data_transfer_object

    http://www.mindscapehq.com/documentation/lightspeed/Building-Distributed-Applications-/Building-WCF-Services-using-Data-Transfer-Objects

    And the use of 'object' if it is in the Datacontract is proably going to be trouble, since it is not a known type object, and  it is a base object of all .NET objects.

    I have implemented INotifyPropertyChanged In thisPOCO.  -- This may be trouble too if it is being used in the Datacontract as it is going to get fired in the serialization and deserialization process marking the object as dirty erroneously when nothing changed in the object.

    What should be bound to the UI is what I call a SmartDTO that knows that xan set its state, which is based on the principles in the link.

     http://www.dailycoding.com/Posts/maintaining_dirty_and_new_state_of_objects.aspx

    The DTO that you send between the WCF client and service is a dumb DTO that just has all the public properties and private flags in the SmartDTO mapped to public properties in the dumb DTO. The dumb DTO is hust using auto propties like Name String {get; set;}

    You get the dumb DTO back on the WCF service side they you can check it. The dumb DTO is sent form the service to the client where you map it to the SmartDTO and use it at the UI. You can't send the SmartDTO through WCF becase the MarkDirty() fuction will get fired in the serialization process.

    If IsNew and IsDirty = insert into database

    If !IsNew and IsDirty = update existing data in database

    If IsDelete = delete data from database.

    As far as object property mapping, there is AutoMapper, and you can make object mapping as simple or as sophisticated as you like.

    http://www.codeproject.com/Articles/61629/AutoMapper

    I use this stuff all the time in N-tier or when WCF is invloved and data persistance is sitting behind the WCF service.

    Tuesday, May 19, 2015 8:26 PM
  • Your information and the links you provided are very helpful. Thank you.
    I am being very specific about what gets into the database and the service is doing all the work for that - the UI is nothing but a front end for watching what is happening, and also to generate a pdf report from what is in the Database.
    It will be an intranet application talking to the service  I have a list of items that I need to real time update, and I also have a list of 30 elements indicating a percentage of maximum (x of max 50) in percent also real time.
    The service is doing the heavy lifting, which monitors data from a server ( 3rd party type). Which this works I can get data on a datachange , and I can read data , or even write back data.

    So I have the data coming back and I need to map it to the Properties of a DTO or a POCO - the IsDirty from the example does an automagical save function kind of nice. I am controlling though what gets saved, I have a trigger that comes to me via an Item (but I need to know the Item is that Trigger - I only have the client ID as a reference) then I need to read and set values on some other items - here is the difficult part the items are a simply a flat [collection of a collection of items] - I have no way to sort , or quickly map that to the properties of anything. [I have seen AutoMapper on the web but I am reluctant to try to learn that too - as you can see I am learning WCF, and then some..

    The service is just pushing the Data to me.
    So I am not sure if the Is Dirty flags will matter , but maybe they will - I was hoping that any changes in the WCF service will automagically be reflected in my Datagrids on the Winform UI. Which is why I implemented INotifyPropertyChanged .

    As I am looking at what a DTO is [https://msdn.microsoft.com/en-us/library/ms978717.aspx] , it appears as if the whole object is passed Get/Set this dumb object pass it from one side to the other and work with it, like a middle man, the real work is done by a smarter object - but the simplistic object is passed. Is that it in a nutshell ? Low overhead , simple object.
    Would this be accurate ?


    When you think there is no way, there is a loophole. When you have made it idiot proof, they come out with a better idiot.

    Tuesday, May 19, 2015 9:24 PM
  • As I am looking at what a DTO is [https://msdn.microsoft.com/en-us/library/ms978717.aspx] , it appears as if the whole object is passed Get/Set this dumb object pass it from one side to the other and work with it, like a middle man, the real work is done by a smarter object - but the simplistic object is passed. Is that it in a nutshell ? Low overhead , simple object.
    Would this be accurate ?

    The simplistic DTO is passed between the WCF service and client because of the Datacontract XML serlization of the object that is going to firer in the getter and setter if logic is in them. If the setter has the MarkedDirty() method in it, then the IsDrity flag is going to be set to true becuase the object was past between the WCF service and client in either direction and marking the object as dirty when the object should not be dirty.  The only time the object should be marked dirty is becuase of a true interaction of  code setting data in the object's property and not becuase it was sent between the WCF client and service and XML serialization happened on the object on the trip firering the getter and setter.

    Take WCF out of the situation and you were sending SmartDTO(s) up to the UI. The fact that you set data in the object property form the database is going to mark the object as dirty. But before the object is used up at the UI,  which is an old object and existing object from the database, the object must be marked as old Markold(), which is a function in the object from the link about setting the object's state.

    If WCF was not in play, you can just use the SmartDTO all the way. But becuase of the XML serlization taking place with WCF on the object, you can't send the SmartDTO, and you have to send the dumb one that has no logic in it on the getter or setter based on what will heppen if either the getter or setter has logic in them during object serialization.

    Tuesday, May 19, 2015 10:03 PM
  • Thank you again for your reply. I just need to make sure I am understanding correctly and in context of what I am trying to achieve. I have a 3rd party server service that acts much like a data pump - it has an event that fires - I catch that event in my client (which is running as a WCF service hosted in a windows service) , based on the data that I receive; I make a read request and get a callback argument of ItemValues[] , now I am going to update a database with that callback data (with in my client - the WCF service) and also update a Client Object - basically a list of the ItemValues in a column/row format.
    ItemValue[0].Path[0].Property1
    ItemValue[0].Path[0].Property2
    ItemValue[0].Path[0].Property3 
    Is a row with 3 columns where path would change for the next row.
    From that Client Object I want the changes to be reflected in the UI with out rebinding etc.
    My Client Object can be a simple DTO dumb object , I just need to make sure that the updates to it are reflected in the UI - automagically and maybe I am missing the point here - but perhaps following the employee example you provided - when I set the values of the Client Object the IsDirty flag would be set and the object is updated? [The employee sample looks like a bit more than getter/setter - is that considered a DTO or is that the smart DTO?].
     I have never used WCF before - so when they talk of binding - I am hoping I can bind my grid to the wcf Client Object .

    Do you know of any project code similar to this or samples that I can look at to do this ?
    I am sure my happy meal is missing the french fries .

    When you think there is no way, there is a loophole. When you have made it idiot proof, they come out with a better idiot.

    Wednesday, May 20, 2015 2:21 PM
  •  

    but perhaps following the employee example you provided - when I set the values of the Client Object the IsDirty flag would be set and the object is updated? [The employee sample looks like a bit more than getter/setter - is that considered a DTO or is that the smart DTO?].

    The Employee example in the link is really about a business object in a Business Layer being used in a n-tier application. I took the concept and applied it to DTO(s) making the DTO set its state when code sets one of its properties with data. - the SmartDTO. The DTO is what is carring the data between the tiers/processes. The fact that the UI code in some way interacted with the  DTO and changed its content sets the DTO state to dirty. The DTO could have had a property changed in the Business Logic Layer,  or the DTO can have its dirty flag set in the DAL by the DAL making a chenge to the DTO.

    But the bottom line is this . Whatever logic is going to take the DTO's data and persist it to the database, the logic needs to kown the state of the DTO.

    Is the DTO's state dirty? If it is,  then the logic is going to do something with the DTO to persist its data to the database.

    If the DTO's state is new and dirty, then the data is going to be inserted into a database table.

    If the DTO's state is not new and dirty, then the logic is going to take the DTO's data and update an existing table record in the database

    If the DTO state is delete, then the logic is going to delete a record from the database.

    If the DTO's state in not dirty or delete, DTO is ignored/bypassed for persistance with the database.

    The only code a SmartDTO has in it is the flags that indicate state and any methods() that deals with the state flags. The concept of a CSLA Business Object is a lot more complaicated than what you are seeing even in the link provided, The simplistic part about the object state was ripped out of the business object and applied to the DTO, which would be DTOEmployee - the SmartDTO. The simplistic part about the object's state is being talked about in the link. 

    The DTO that travles between the WCF client and service adhear to the below principles it is dump object

    http://en.wikipedia.org/wiki/Data_transfer_object 

    <copied>

    The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing

    <end>

    The SmartDTO has behavior/methods the strickly and solely deals iwth the object's state. It has no other logic or behavior   other then object state behavior.

    You can't send the SmartDTO through WCF in either direction, which has been explained as to why you can't send the SmartDTO.

    You have to map data between the SmartDTO and DumbDTO and vice versa.

    Where the concept of an object keeping state is out of the books.

    http://www.barnesandnoble.com/listing/2671620427874?r=1&kpid=2671620427874&cm_mmc=GooglePLA-_-Book_45Up-_-Q000000633-_-2671620427874

    Books are 2003, 2005, 2008 and so on.

    Wednesday, May 20, 2015 6:36 PM
  • Thank you , as this is all been very helpful, I am learning WCF,  and all of this info is very helpful!  I will start reading some more and experimenting some. Thank you.

    When you think there is no way, there is a loophole. When you have made it idiot proof, they come out with a better idiot.

    Thursday, May 21, 2015 2:09 PM