none
Using WEB Services At Data Access Layer RRS feed

  • Question

  • Hi
    I have defined an architecture for distributed application using dotnet 2008 c#.
    Here is the brief intro of that
    UI --> BusinessFacade --> BusinessLayer -->DataAccessLayerFacade -->(DataAccess Classes and Webservice as wraper)
    i am using DTOs and Typed Datasets as well to transfer the objects between layers.
    My Question is once returning the typed dataset from webservice to the Business Layers will cause the performance down.
    or is there any other way to use webservices and get the typed datasets with low cast.
    I think once you will have 1000s of rec in a single table then it will slow down the application.
    I am also thinking to use WCF and have some proxy classes on server and cache the data over there.
    again while traveling data on network will again be a costly method
    Can we Compress that data and decompress that on dataaccess Facade layer
    or any solution
    Friday, July 17, 2009 7:29 AM

Answers


  • Umer,

    Depends on what you want to achieve with your caching, and also how quickly the cache becomes stale, as to the approach you take.

    If you're doing anything more complex than loading static data once, and storing for the lifetime of the application, then I would recommend the caching application block.  It's very powerful, and will allow you to store data, and refresh when something external that you're moniroting becomes stale.  You can also use it more like a dictionary, but with an expiry policy.  The key in this case is to build up a cache key to use that represents a unique combination that will allow you to pull data out relevant to the changing parameters / attributes of the subsystem in question.

    Then you call the caching application block from within the facade, so the data has already been through the business layer when it is stored, and has to go no further to apply any other rules.

    Hope that helps to start you off, please let me know if there's anything more specific that you need information on.

    Thanks,

    Martin.
    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    • Marked as answer by Umer Draz Monday, July 20, 2009 9:24 AM
    Monday, July 20, 2009 6:06 AM

All replies

  • Personally when talking of performance, I wouldn't use a dataset - you have a lot less control over it than you do dtos made up of entities and collections that you create yourself, also the dataset includes overhead for other functionality that you may not need.  Sure you can switch it off, but then you have to question what the point is in using the technology.

    Is there a reason, other than so you can use WCF, why you are service enabling the data layer?  Do other applications also call into this?  If so, how do you enforce business rules if you byass the business layer?

    The service calls would typically sit in the business facade, as they can be transparently switched in and out without affect the call flow or caller.  That means you can develop without WCF to start with, then enable WCF when you have a reason to do so.

    If you're going to be returning 1000s of records across any service, you have designed your application wrong.  Who ever searchies through in one attempt, thousands of records?  If you scroll, page, you're splitting the data, therefore you split the calls, and limit the results, thus stopping the big performance hit.  If you're wanting to have the data in memory, you can cache it at the business facade layer, before you call into the service.  In this way, if you already have the data in the cache, no overhead is spent in calling out to the data layers over a service and serialising and deserialising the data.

    Compression is a possibility, but you really should need it if you have designed the application in such a way that you return the data that you need only, and then by all means cache it, if it makes sense to do so, and you get subsequent cache hits.

    I hope this gives you a few ideas to think about, and some things to go and research, then come back and ask a few more questions, and I will try to help you with a bit more advice.

    Thanks,

    Martin.

    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Friday, July 17, 2009 8:52 AM
  • Thanks Martin for your post
    I have a windows Forms based Application which will work in distributed environment thats y i want to have WCF.
    You raised another very good point to have Service in Business facade layer rather then DAL
    Thats helpful for me
    Another thing is how to use caching in Windows based application can you help me doing that?
    can you suggest me the best architecture for that

    Friday, July 17, 2009 12:09 PM
  • Umer,

    I would say, Martin point about typed datasets is really valid and best would be if you can get rid of these.

    As long as caching question is, for window applications one approach is to go for compactDB. Let me tell how we are using it in our application. Its window based solution and we were getting great performance hit on populating lookup data on load of every form. After doing some analysis we found, compactDB could solve this problem and it did.

    Approach is we keep lookup data in compactdb file which is part of window application. When ever there is some change in server side lookup data, synchronization process runs and it synchronize compactdb. Otherwise window app keeps on using compact db for lookup data.

    Thanks.
    Attiq

    • Proposed as answer by kdas Friday, July 17, 2009 5:05 PM
    Friday, July 17, 2009 2:28 PM
  • Hi, Umer
    I am agree with Martin about the Dataset, you can use DTO without Dataset this will enhance the performance, using Reader still the faster way.
    About the cashing.
    Your whole architecture is very well for me I almost use it in my last project but with little diffrent, I do the Data facade but not exposed it as services, I also cash the DTO in the DAL I use pattern and practise guide in cashing which you can find here
    http://msdn.microsoft.com/en-us/library/ms978498.aspx

    you can also use Caching Application Block which included in the enterprise library
    http://msdn.microsoft.com/en-us/library/dd203226.aspx

    Thanks


    We are volunteers, if the reply help you mark it as your answer. thanks!!
    http://mohamed-radwan.spaces.live.com/default.aspx
    Sunday, July 19, 2009 6:47 AM
  • Thanks to all who replied to this post
    Attiq you suggested to use the COmpact dbs. thats better solution as we need to use a lot of lookup tables and we can define some sort of mechanism using XML Files etc.
    Thanks Radwan let me see that enterprise liberary Caching.
    I am already using the Data Access Block for application

    Monday, July 20, 2009 6:00 AM

  • Umer,

    Depends on what you want to achieve with your caching, and also how quickly the cache becomes stale, as to the approach you take.

    If you're doing anything more complex than loading static data once, and storing for the lifetime of the application, then I would recommend the caching application block.  It's very powerful, and will allow you to store data, and refresh when something external that you're moniroting becomes stale.  You can also use it more like a dictionary, but with an expiry policy.  The key in this case is to build up a cache key to use that represents a unique combination that will allow you to pull data out relevant to the changing parameters / attributes of the subsystem in question.

    Then you call the caching application block from within the facade, so the data has already been through the business layer when it is stored, and has to go no further to apply any other rules.

    Hope that helps to start you off, please let me know if there's anything more specific that you need information on.

    Thanks,

    Martin.
    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    • Marked as answer by Umer Draz Monday, July 20, 2009 9:24 AM
    Monday, July 20, 2009 6:06 AM