locked
general beginner web services questions RRS feed

  • Question

  • I'm new to web services in general, so forgive my ignorance.

    I'm trying to create a web service from my web app, but I'm confused on some key architectural concepts.

    First a little background... data flows through my app in the following way...

    1. database (with stored procedures that return the data)

    2. .net data access layer (that calls the stored procedures)

    3. business logic layer (that accesses the DAL and builds custom entity objects or generic lists of these objects)

    4. Custom Entity classes 

    From what I understand, with ADO .net web services, you build web services using data entity objects built off the database. What confuses me, is how the business logic would then fit in. Ideally I would like to build them off my custom entities and generic lists of them. Am I going about this completely wrong? Any help would be really  appreciated.

    Saturday, March 20, 2010 5:04 PM

Answers

  • Hi,

    From the data services point of view there's no real downside. Depending on your amount of data, the complexity and number of users it might be OK to hold all of your data in-memory. So if you know that this is not a problem for you, there should be no down side. Unless you're going to provide some other IQueryablt than the one from LINQ to Objects, in that case you need to make sure that such IQueryable can handle all the same queries we are going to use against the LINQ to Objects one. If it can, then there's no downside either.

    Thanks,


    Vitek Karas [MSFT]
    • Marked as answer by amonteiro Wednesday, March 24, 2010 9:12 PM
    Monday, March 22, 2010 9:34 AM
    Moderator

All replies

  • Hi,

    You don't need to use EF as the direct provider of your data in WCF Data Services. If you have all your data in memory you can use LINQ to Objects and the so called "reflection" provider instead. In your DataService<T> you provide your own class as he T. Any property of that class which returns IQueryable<E> will be treated as an entity set and exposed as such. The E is then the entity type (not EF thing, just a class describing the entity). How you get the IQueryable depends. If you have all your data in memory, you can use the List<T>.AsQueryable method and everything just works. If you don't, you could implement your own IQueryable (but this is rather hard).

    Thanks,


    Vitek Karas [MSFT]
    Sunday, March 21, 2010 8:52 PM
    Moderator
  • Great thanks, your explanation and this video http://msdn.microsoft.com/en-us/data/cc745968.aspx are starting to piece things together. I guess my only other question, is if doing it this way has any downsides? or is not recommended for any reason?

     

    Sunday, March 21, 2010 9:19 PM
  • Hi,

    From the data services point of view there's no real downside. Depending on your amount of data, the complexity and number of users it might be OK to hold all of your data in-memory. So if you know that this is not a problem for you, there should be no down side. Unless you're going to provide some other IQueryablt than the one from LINQ to Objects, in that case you need to make sure that such IQueryable can handle all the same queries we are going to use against the LINQ to Objects one. If it can, then there's no downside either.

    Thanks,


    Vitek Karas [MSFT]
    • Marked as answer by amonteiro Wednesday, March 24, 2010 9:12 PM
    Monday, March 22, 2010 9:34 AM
    Moderator