locked
External vs RIA Data Sources RRS feed

  • General discussion

  • This is a follow on question to this post:

    Intrinsic vs External

    If one has decided that the External database will better match the long term needs of the solution, what are the pros / cons of connecting LightSwitch to the external database versus using RIA as the middle layer between LightSwitch and the external database?

    To make certain I am clear, the entire data layer would go through ria.


    Thank you, Bill



    • Edited by jessiedog Monday, June 17, 2013 6:57 PM
    Monday, June 17, 2013 6:45 PM

All replies

  • Using an external database does not mean "by definition" that you need a RIA service.

    You can also use a RIA service over the internal (intrinsic database).

    My recommendation would be to use as much as possible the internal database approach (and use all lightswitch goodness out of the box) and only use RIA services if you have no other option. We enjoy now version 3 of LightSwitch, and the team really did a great job, to keep things extremely well backwards compatible.  One day, anyhow, you will need to upgrade your silverlight projects to html5 clients. Now, I hear you thinking: that's about the client side. Indeed, a RIA services is mainly (but not completely) a server side technology. But RIA services, as a technology,  is tied very close to silverlight. When you consume in LightSwitch a RIA service, the consumption of the RIA service happens completely in process server side. The exposition of the data towards the client is already now REST/ODATA. In other words, the client is not aware of the ria service.  When you would think in a complete html scenario,  this RIA scenario is probably not completely future proof (for the really long term).

    Agreed, when you want to build a screen (with all lightswitch goodness) based on a data structure that deviates from what LS can handle, you need a RIA service, but for things like reporting (where you need even more often all types of aggregations), I would go for Web-Api.


    paul van bladel


    Tuesday, June 18, 2013 6:26 PM
  • Paul,

    Ok, I've researched this a bit more.

    If someone is taking a code first approach and then adding RIA services on top of that, what are the disadvantages?

    Basically, I've had three different developers tell me that based on the 200+ tables and data intensive business logic we require; that it would be better to implement using a "Code First" method for the data access layer with RIA service with the business logic.

    Their points are:

    1) Our data structure is more complex that LightSwitch is designed to handle. 100+ main tables with 100+ many to many tables.

    2) The business logic one computation will require accessing 10 tables and reading 150-200 records to "compile" the answer.

    3) The business logic uses a "meta data" approach which requires RIA. No way to do it in Lightswitch.


    Thank you, Bill


    • Edited by jessiedog Thursday, July 11, 2013 4:54 PM further explanations
    Thursday, July 11, 2013 4:07 PM
  • All,

    I would enjoy any further comments!

    That said, I think I found an answer posted by Yann related to the database first concept as opposed to the code first concept but as Yann says, it is all the same for this answer.

    http://social.msdn.microsoft.com/Forums/vstudio/en-US/00807567-aec1-4e0a-a9ce-f3dd9abd8677/ls-wcf-ria-entity-framework-database-first-using-designer

    Again, any further thoughts would be welcomed!


    Thank you, Bill

    Thursday, July 11, 2013 7:54 PM
  • Hi Bill,

    Nothing interesting for me to add to what I wrote already above and what Yann wrote.

    Only use a RIA service if you want to

    - change the shape of the data and consume with the lightswitch goodness these shapes in screens (if you need a deviating shape but consume it only server side, eg for reporting, use web-api)

    - connect to data sources where you need full control (in code).

    If you use db first + a ria service without the above constraints, you are just making life difficult, and add additional layers acting as an empty box.

    My advice is, when you have few insight in potential constraints, then don't try to make too much upfront design on constraints that you didn't came across yet.

    In other words (and that's really agile), no upfront design for unknown problems :)

    So, start with the out-of-the box scenario (LS intrinsic db approach) and see where you get.


    paul van bladel


    Friday, July 12, 2013 10:41 AM
  • Paul,

    Thank you for your input.

    Your contributions to the Lightswitch community are great!


    Thank you, Bill

    Friday, July 12, 2013 4:48 PM
  • Thank Bill. Very much appreciated.

    paul van bladel

    Saturday, July 13, 2013 12:26 PM