LINQ to SQL to Datagrid : showing additional user (defined during runtime) properties

Answered LINQ to SQL to Datagrid : showing additional user (defined during runtime) properties

  • Wednesday, November 14, 2012 11:03 PM
     
     

    Hi there !

    Maybe I am missing / misunderstanding something but i still not have find a way to produce the following "simple" scenario:

    - A window is dealing with a Customer Order that is made of Order informations (id, date, blahblah, ...) and OrderLines (lineid, itemid, qty, blahblah, ...)

    - Order object is beeing retrieved using a linq-SQL query; Order lines (OrderLines property of the Order linq object, from datamodel structure) is binded to a DataGrid

    Users can use the DataGrid to update database records (using the DataContext commit)

    I would like that DataGrid showing additional user-defined properties / columns. Those properties values are computed from simple SQL queries result (SELECT a + B from MyCustomTable), expression strings refering to other properties names for calculation ("value = obj.prop2 * obj.prop1 * n"), ... that are defined by user at runtime.

    Those additional properties will not have any impact on the database, it's only a "read-only helper" for the user. BUT other existing db properties contained in the Linq-SQL "base" object definition have to be managed/updated.

     I search about extending the Linq object but I do not find the proper way to do it. Any help / ideas are welcome!

    Hereafter are some findings I made and what I currently think of them through comments and readings ...

    Many thanks in advance!

    Context: .NET 4, WPF, Linq-SQL

    - I think I can't extend through partial class definition as it does not fulfill my "runtime definition" requirement; moreover, I don't want the object class to be globally modified (for entire application) as those properties will only be required on a single datagrid; other views may implement others different user-defined properties for that same object.

    - anonymous linq results should be avoided because of limitation it brings for DataGrids (loosing DataContext bindings => loose the add/update/delete to the database features) ; then, I am not sure that I can that "Dynamic Linq-SQL" queries while iterating the object properties from a collection (the collection containing each user-defined properties/columns definition - propertyHeader, propertyName, propertyValue computing logic)

    - I also read about defining additional datagrid columns while the DataGrid content is updated (new ItemsSource binding, update events ...). I didn't find any working samples and moreover, I'd rather prefer having those "additional runtime properties" built into an "updated" object : this one could also be used elsewhere in the view (child "order line detailed view" for example) in order to be able to reuse the same logic centrally built/managed.

    - "dynamic" object definition may be a solution but I still not know if it will keep the binding beetween the Db related properties and the datacontext (may I have to rebuild all the update/delete/... binding logic ?).

    - lastly, it seams that the lightswitch "computed properties" is exactly what I am looking for (except I don't know how i can bind SQL query result, evaluated expressions, ... on them) but I did not find this "computed property" feature outside a lightswitch project!

    • Edited by jpbenard Wednesday, November 14, 2012 11:10 PM
    •  

All Replies

  • Friday, November 16, 2012 7:26 PM
    Moderator
     
     Answered

    It seems like you have designed yourself into a corner. Here is my advice, one and two are independent of each other.

    1. Create a new entity (outside of Linq2SqL or EF) which combines all the goodies needed and have Tag object which coorelate(s) to the original entity(ies). Then when someone edits the data, change the data held on the Tags and send it back, or simply do the CRUD operations programmatically; old school. I designed a high transaction business application doing that method which didn't use the EF goodies of saving and processing entities, because it freed me to do the things needed.
    2. Or use the partial class and put on the properties needed, extend as you say. I am not sure what you mean by runtime definition, but it seems nitpicky, no offense, because it stops you from extending the entities for a runtime situation which is frankly perfect for this scenario.

    Just my thoughts....


    William Wegerson (www.OmegaCoder.Com)