locked
Any reason not to process *all* my table data through WCF RIA Services? RRS feed

  • Question

  • Pardon me if this has been asked before, I didn't see it.

    I've been working a great deal with RIA Services now, and find it absolutely essential. Some of the data I will be displaying to the user for editing and such doesn't need to go through RIA Services, it's very simple.

    However I've noticed a few things. On occasion I will need a relationship between an RIA Service table and a table from my database workspace. Having relationships between data workspaces gets akward very quickly. I attempted this but ended up moving that bit into RIA Services and setting up the relationships there and I'm far more satisfied with this solution.

    Also, who's to know what the future may hold, it's entirely possible my simple table will need some special additions in the future and I will need to migrate it to RIA Services anyway.

    I'm leaning strongly toward eliminating my direct-database workspace from my LightSwitch project and having all of my data flow through RIA Services. There isn't too much left to migrate. It seems like it would have a great effect on minimize clutter and complexity. Is this a recommended approach? The only possible drawbacks that occur to me is performance might be hindered, and *maybe* having lengthy code for simple data in RIA Services will be bothersome, but this still seems better than dealing with dual data workspaces, plus I can write helpers to shorten things.

    I'm not particularly concerned about performance at the moment and if it does become an issue I will address it where needed. Simplification and maintainability is my first goal here.


    Thursday, April 4, 2013 5:59 PM

Answers

  • Just a quick follow up. I did this and it was absolutely the right way to go. Having some tables direct from the database in one data source and other tables from RIA Services in a separate data source was terrible. Relationships between them was even worse and terribly problematic. Now I have just an RIA Services data source and it's fantastic, everything is so much easier, performance seems just fine. The only minor gotcha is with many-to-many relationships that contain only two (both primary key) fields I had to add a "dummy" field so RIA Services would quit doing magic and hiding the table from me. I had to do the same with some one-to-many relationships (I think when there wasn't a nullable field present, but I could be mistaken). Thanks all.
    Friday, May 3, 2013 2:03 PM

All replies

  • What scenarios make RIA services absolutely essential for you?  Have you tried playing with ServerApplicationContext and WebAPI instead?


    Thursday, April 4, 2013 10:12 PM
  • No I haven't. Simply its function as intermediate business logic makes it essential for me, able to take advantage of all of LightSwitch's code generation. I design how I want users to see and interact with my data in RIA Services and LightSwitch does the rest. Creating LightSwitch screens on the database itself is inadequate as the database is normalized and so forth. I haven't looked at those two, I suppose they provide the same middle-tier benefit?
    Thursday, April 4, 2013 10:23 PM
  • SAC lets you create new entry points on the LS server and return arbitrarily shaped data, so its very good for doing reporting and aggregates and rendering the data in the HTML client.

    However, because it returns JSON shaped data, there is no built-in support in the clients for viewing the results directly -- you'll need to implement a custom control.

    I'd like to understand more about why you prefer not to use the entity designer.  What shapes are you making your entities that the entity designer isn't doing for you?

    Thursday, April 4, 2013 10:44 PM
  • I'm not looking at the moment, but I basically accrued a mental checklist for when to use/them (the pluralization of RIA Services drives me nuts I'm never sure whether I should refer to it as a singular thing or multiple things) and it's come out "always" at this point.

    One *major* reason I use RIA Services is because all the properties will be searchable. If I put together a data grid with the entity designer, that has a few columns and then 10 or so other columns brought in by a relationship to another table, only the few columns will be searchable and not the other 10. This is huge, and reason alone to use RIA Services. It's frustrating seeing 13 or so columns and mysteriously only able to search by 3. I believe the same applies to sorting...?

    I don't think I make particularly exotic shapes on my data but one example is I have two data grids that each use a different table from my RIA Services workspace that in truth operates on the same underlying database  table but each data grid is its own filtered view. With a button click a record is added to the table with a couple properties already set (identifying the record as belonging to one or the other). If you attempt to do this without something like RIA Services it's problematic because when you add a new record to one of the tables it will show up on both until you hit save and refresh (client side it isn't aware that each data grid is a different filtered query, it sees that both operate on the same underlying table and displays your new unsaved record in both simultaneously).

    Friday, April 5, 2013 1:54 AM
  • Bump. I'm going to convert the rest of my project to go through RIA Services (at least to try for a while) for the reasons I've given in my first and recent post unless someone has convincing reasons why I shouldn't. Thanks.
    Monday, April 8, 2013 1:23 PM
  • Just a quick follow up. I did this and it was absolutely the right way to go. Having some tables direct from the database in one data source and other tables from RIA Services in a separate data source was terrible. Relationships between them was even worse and terribly problematic. Now I have just an RIA Services data source and it's fantastic, everything is so much easier, performance seems just fine. The only minor gotcha is with many-to-many relationships that contain only two (both primary key) fields I had to add a "dummy" field so RIA Services would quit doing magic and hiding the table from me. I had to do the same with some one-to-many relationships (I think when there wasn't a nullable field present, but I could be mistaken). Thanks all.
    Friday, May 3, 2013 2:03 PM