none
WCF Data Services as Data Access Layer? RRS feed

  • Question

  • I'm working on an reference architecture for my company regarding WCF Services, based on a proof of concept.

    The basic layers are defined by the .NET Architecture Guidelines v2 and created using the WCF Services Software Factory. This means the following structure:

    Client - ServiceInterface - ServiceImplementation - BusinessComponents - DataComponents - SQL

    At the moment the DataComponents contain the EF model to retrieve the data from SQL, but I was wondering if I should use the WCF Data Services for that. This would mean an extra layer between the WCF Service and the SQL database, that hits the performance. On the other hand it adds flexibility to the solution.

    I have been looking for reasons why I would or wouldn't use such an approach. Like described it hits the perfomance, but on the other hand a change in the database doesn't necessarilly mean I have to update the WCF service because it can be handled by the WCF Data Service.

    What are valid reasons for using or avoiding WCF Data Services as a data access layer?

     

     

    Wednesday, December 1, 2010 4:11 PM

All replies

  • Hello there,

    Data access should be separate assembly which is interacting with database. When we are talking about the business component , the business component should be only talking to the data access layer,in the business layer is the layer where business rule and business functionality are added here. You need to add this layer if you have business functionality for your software project.

    Case One flow diagram

    WCF SERVICE <==> DAL <===> SQL DATABASE ( WHEN THEIR IS NO BUSINESS COMPONENT)

    Case two Flow Diagram


    WCF SERVICE <==> BLL <==> DAL  <==> SQL DATABASE (WHEN THEIR BUSINESS COMPONENT)

    Please do create Proof of concept which is best for your software project.

    Regards,

    Phijo Mathew Philip.

    PHIJO MP
    Wednesday, December 1, 2010 4:59 PM
  • Hello there,

    In the dal layer you can use linq to sql or you can  call stored procedure using linq in the side dal layer.  The same return type of methods can be used for the WCF service methods.

    You can proof of concept , which is very good option.

    All the your database operation can be implemented in stored procedures and using linq to sql can be used which can meet your software project functional requirements.

    Some links are given below

    Using Stored Procedures In Linq
    http://weblogs.asp.net/zeeshanhirani/archive/2008/08/05/using-linq-with-stored-procedures.aspx

    Simple 6 steps to use stored procedure in LINQ
    http://www.codeproject.com/KB/linq/6stepsLINQ.aspx

    Regards,

    Phijo Mathew Philip


    PHIJO MP
    Wednesday, December 1, 2010 5:10 PM
  • Thank you for your reply!

    Actually I'm not looking for what needs to be in what layer, because that is very well described in the .NET Architecture Guide v2.

    What I'm looking for is guidance on how to setup the data access layer.

    I can use Linq2SQL or Entity Framework, but what I would like to hear from the field is if it is also a good idea to utilize WCF Data Services for accessing the database in a service project.

    Thursday, December 2, 2010 1:18 PM
  • you can entity framework for the database layer.

    PHIJO MP
    Thursday, December 2, 2010 2:03 PM
  • I actually just posted a very similar question here:

    http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/e678cd01-339d-476f-acf7-12622cc06559

    So if we are on the same page, we are talking about having TWO wcf layers; one as an entry point into the business layer, and another as an entry point into the data access layer.  In my case, they will more than likely be on the same machine so I could use the TCP binding to help increase performance, but am I actually gaining anything?  Simplified maintenance between layers perhaps?  It seems like it may have some merit in a larger enterprise architecture solution.

    Are there others that have seen this type of architecture in practice?  I'm interested to know how it seems to work?

    Thanks.

    Tuesday, March 1, 2011 8:24 PM
  • But,but....it is just a layer :) and that is the beauty in layers you can replace it without any affect on the upper layers in the future

    I think that a 'data access layer' is a correct term only in the context of the entire application

    But as a relation between 2 layers every lower level layer is a data access layer?!

    So just define an interface to the data acces layer and in the future you can replace it

    Personally i do see some advantage in using another WCF service as the data access layer

    And it is all the stuff WCF brings,context,activation,permission,logging,state (if needed) ...so the question do you need this "stuff"?

    Tuesday, March 15, 2011 6:43 PM
  • Hi jean,

                    Here you go. All the architectures would have some advantages and disadvantages. But, “is the architecture suitable for our need?” is the question here. Based on the requirement we can decide whether we need to use WCF Data Services or not. If I understand your question correctly, you are expecting the justification / reason / scenario where we can use WCF Data Services and when not to use.

    Technology and Architectural Pattern selection is based on the following basic and important criteria (in short NFRs).

    1.       Scalability

    2.       Security

    3.       Performance

    4.       Deployment Model

    Layered Architecture is one of the Architectural Patterns.

    If your application is huge geographically separated enterprise level one with thousands of concurrent users then I would suggest you to go ahead with WCF Data Services.

    The advantages are,

    1.       Scalability

    2.       Loosely Coupled Data Layer Implementation

    3.       Security

    4.       Performance [The service modeling and OO Design should be good enough]

    5.       Distributed Deployment

    If your application is small and not the distributed one, you can consider using EF in an assembly and deploy in a single environment [I am not saying single server]. Your current architecture is suitable in this scenario.

    Everything should start from the requirement and scope. If you go in that way you should be able to figure out the right solution and architecture. Let me know if you need any clarity on this.

    Cheers,
    Paras


    -- Paras
    • Proposed as answer by Paras B Wednesday, March 16, 2011 6:39 AM
    Wednesday, March 16, 2011 6:39 AM
  • wcf data service can used only for wpf client , asp.net with silver light which usess oData protocol. 

     


    Tuesday, March 22, 2011 12:45 PM
  • I think one valid reason for not using WCF data services is that you're developing in Silverlight.

    WCF RIA is IMO a better option.  If only due to the validation stuff.

    There again I can't see how that really fits in with the OP's question and it's probably way too late since he asked it 3 months ago.

    Wednesday, March 23, 2011 8:46 AM
  •  

    Any one who knows how to issue a HTTP call can use wcf data service.

    Saturday, March 26, 2011 3:15 PM
  • Hi,

    WCF data service is an interface service which supports and easy interface to be used by the client applications (Open Data Protocol (OData), REST).

    there has to be a DAL to get the data from the underlying repositories 

    there has to be a business logic layer if any logic is there

    so it is up to the requirements of the application to use any combination of the WCF DS , DOL, DAL

    The major decision here is whether to use WCF DS or not. Once it is decided then all other decisions are not any complex. It depends on the type of services that the application is providing. 

    Some cases, there will not be any business rules involved, mostly querying the resource s using REST or updating the resource. Security and data access should be sufficient here. All the users will be treated with same role and have the priveleges to perform any action. 

    It depends entirely on the 'kind of application' you are building.

     

    WBR,

    prasadpnvrk


    regards, pnvrkprasad
    Sunday, March 27, 2011 8:01 AM
  • There seems to be a lot of misinformation about WCF Data Services, you can do a fair bit with it. But as already mentioned, it's focus is really on clients that consume string data, i.e. xml, atom, odata, json, etc...so probably isn't a good choice for the only channel into your data but it's not all you use it for. Microsoft would obviously like you to back it up with EF which is when it becomes tempting to use from a client as you can avoid firewall issues and still have automatic change tracking. Just to add, some of the features it does have are; role based security both on the underlying entity and the operations, good support for paging, limiting the depth (and bredth) of lazy loading, query/change interceptors for custom rules.

    BTW you are NOT restricted to Microsoft clients, that is just plain wrong advice.

     


    http://pauliom.wordpress.com
    Saturday, April 2, 2011 8:07 AM

  • Hello Jean Paul,

    I would not use WCF for the data layer:

    1. To Increase the data layer performance
    2. You can use TCP/IP protocol to communicate with database server without any webservice
    3. Maintenance: it would harder to maintain a WCF service and the data layer.

    But, It is important to have a WCF service between UI (ASP .NET, Silverlight, Winform, WPF, PHP, JEE ...) and Business layer for:

    1. Interoperability : WCF is WS-I, thus you can use it with PHP, JEE and different UI
    2. Performance (N-tiers): - database server - Business server - UI server
    3. Maintenance: It is easy to maintain.
    4. But the problem of EF is that you have to recompile code to fix a bug on a procedure. If you use procedures on SQL server directly, all you need to do is to alter the proc and thus no code to recompile and no code deployment.

    For your POC, you can start by making one business service contract and use it in the UI to show that your application is SOA oriented.

    It is really important to make a POC for SOA oriented architectures to show that the project could be done before to start it for real especially on an agile Scrum project.

    Kind regards,

     

     

    Saturday, April 2, 2011 8:06 PM
  • Whilst I agree with most of the points I would like to point out a couple of "issues".

    1. The arguments of using stored procedures or ORM to access a database are long and well documented, but I would not simply state that using stored procedures is an advantage. E.g. if you change the schema stored procedures may have to change but an EF mapping may not. Indeed if you distribute your mapping files separatley then EF can be a good way to avoid any changes

    2. POC objects are not a sign of SOA. Would you probably want to use them, yes. SOA is about the encapsulation of capabilities not the types it consumes or issues.

    3. Performance - skipping tiers to improve performance is perfectly valid. Consider CQRS with WCF Data Services to provide an interesting balance of speed and client interop for reads.

    I.e. it's a big and diverse subject, you may need different mechanisms to solve the problems.


    http://pauliom.wordpress.com
    Monday, April 4, 2011 11:38 AM
  • I agree about the solution, i think you should useWCF when client send request to  Business Layer, the request can be packaged  by the message ( may be DataSet) and send  it to BU through by WCF

    The diagram:

    Client < ===> BUL< ==> DAL <==> DBMS

    Hope for help!

     

    Hello Jean Paul,

    I would not use WCF for the data layer:

    1. To Increase the data layer performance
    2. You can use TCP/IP protocol to communicate with database server without any webservice
    3. Maintenance: it would harder to maintain a WCF service and the data layer.

    But, It is important to have a WCF service between UI (ASP .NET, Silverlight, Winform, WPF, PHP, JEE ...) and Business layer for:

    1. Interoperability : WCF is WS-I, thus you can use it with PHP, JEE and different UI
    2. Performance (N-tiers): - database server - Business server - UI server
    3. Maintenance: It is easy to maintain.
    4. But the problem of EF is that you have to recompile code to fix a bug on a procedure. If you use procedures on SQL server directly, all you need to do is to alter the proc and thus no code to recompile and no code deployment.

    For your POC, you can start by making one business service contract and use it in the UI to show that your application is SOA oriented.

    It is really important to make a POC for SOA oriented architectures to show that the project could be done before to start it for real especially on an agile Scrum project.

    Kind regards,

     

     



    Monday, July 11, 2011 7:57 AM
  • Wow, I didn't know this thread was still being read! (need to set an alert next time)

    I'm planning to use a WCF service interface to let clients communicate with the back end, there is no discussion about that.

    The question is about the data access. I have a database with a lot of tables and I would like a number of services to be responsible for communicating with a set of related tables. So no data access directly, but always via a service. These service supply data operations. I don't want to have stored procedures in the database because that is mostly leading to hidden business logic in your data layer.

    On top of that I think about a layer of composite service. These services use one or more data services to implement process operations. This is the layer that is also communicating with the clients.

    Why would I add an additional data services layer?

    I read the replies and like always there are pro's and con's.

    The biggest risk for is performance or performance loss to be exact.

    The biggest advantage is flexibility. It will allow clients (if necessary) to call the data operations to access the data directly, without having to call the process operations.

    Any other thoughts?

     

    Friday, July 29, 2011 2:13 PM
  • I think there are a number of pitfalls in your assumptions, not incorrect statements but perhaps they're based on fallacies? If you partition your services to be responsible for only their area then you can implement the '3 layers' in each "service" project. The big advantage of this is you get clean separation of concerns (basically it's the premise behind SOA). If you delve a bit deeper into this model then assumptions such as stored procedures hide logic don't necessarily hold. E.g. when you maintain the service you want to have as much relevant code in a small area, in this case it might be a single project with 3 layers in it (personally I opt for a small solution with the 3 projects). The point is that you can easily locate the code you need to change. There is no getting away from the fact that sometimes stored procedure (or even just direct sql) calls are the best solution. What I'm really saying is don't restrict the technologies to fit some idea of a pattern, be pragmatic.

    So after I've waxed about SOA it may well be overkill for your project. Perhaps you need to have a plugable/swapable database, in which case some form of data access layer or ORM would be an advantage. If not then is database security via schemas required? Do you need to provide lots of security filtering to the data? If not why not just use WCF Data Services? Perhaps you need high performance reads - consider CQRS. Perhaps....you get the drift. The technologies and patterns attach to certain problems better than others. You need to consider (or provide here) more information about the non-functional requirements before you can look at the best fit.


    http://pauliom.wordpress.com
    Wednesday, August 3, 2011 4:13 PM
  • Hi,

    I think if you introduce WCF Data Services to expose your Data layer, you are actually creating a new "tier". Take note that layering refers to the logical separation of code whereas tiering refers to the physical distribution of your code with different call boundaries which can either be on the same or different machine.

    Exposing the data layer through services is only good when you are planning to have an "Enterprise Data Bus" where you may have an Operational Data Store (ODS) that is serving data to multiple systems for processing. This way you are able to support systems of different platforms and also providing a single version of truth for your data.

    If your data layer is only serving one application and you foresee there are no other systems who will access the data in raw, then there is no point having a data services tier as it will impact your performance.

    Services layer should be flexible. If you do not see a need for your data layer to be exposed via services now, you can just reference your data access components from your business components. When the need for integration with other system arises in future, you can proceed to develop the data services then for those systems.

    If you have hints that other systems may be accessing your data and there maybe a chance that your RDBMS may change in future, you can proceed to develop the data services now. If you are deploying your data services with your business components in the same machine, you should be using netNamedPipeBinding for best performance.

    Personally, I will not build the data services unless I am building an ODS for a data warehouse.

    I will build the system as illustrated in the Layered Architecture Sample for .NET and have other systems or different UI platforms (including Silverlight or MVC) to access my services layer which in turn goes through my business components. This is to ensure all business rules and validations are the same and executed uniformly for all systems.

    Hope it helps

    Hugs,
    Serena Yeoh

    Thursday, August 4, 2011 12:24 PM
  • i agree with FireDancer. Also, WCF  would not use for data Layer. WCF is just for Service Layer.  Alot of Architech books will recommend you to use WCF as Service Layer for enterprise web application. Presentation layer communicate with the business layer through the services layer.

    I normally just have my Service layer call my functions/methods on the Business layer. 

    example:

     

    public interface IBook { 

    [OperationContract] 

     list<Book>GetBooks(); 

    }

    on svc file

    public list<Book>GetBooks()

     

    {

    using (BookBusinessFacade Book= new BusinessFacade

    ())-- this is from business layer.

     {

     return Book.GetBooks();

     }

    • Edited by eilesss Saturday, October 22, 2011 12:46 AM
    Saturday, October 22, 2011 12:39 AM
  • <services>
        <service name="DataServiceHost"
                 behaviorConfiguration="DataServiceBehavior">
            <endpoint name="DataServiceHost"
                      address=""
                      binding="webHttpBinding"
                      contract="System.Data.Services.IRequestHandler" />
    
        </services>
    </services>
    <behaviors>
        <serviceBehaviors>
            <behavior name="DataServiceBehavior">
                <serviceDebug includeExceptionDetailInFaults="true"/>
            </behavior>
        </serviceBehaviors>
    </behaviors>

    It sounds like you are only seeing the generic "Response Error" message. To see the details of that message you need to modify the behavior to "includeExceptionDetailInFaults". You can change the behavior in your config file.
    Monday, July 2, 2012 7:19 PM
  • Hi Paul 

    based on my understanding of working with different data access technology my rule of thumb is below 

    WCF Data Service 

    1. WCF Data Services are not Q/A type of web services, there whole purpose is to increases reach of your data on multiple platform at the cost of performance.
    2. I would go for WCF Data Service   if I have to provide /expose my data to several consumers including non Microsoft and devices 
    3. I I am the only consumer of service and building web application that will be centrally deployed then I would prefer to stay away because of overhead involve (creating data service need a web application and it would cost $)
    4. If i am consuming someone else data service that we have no option than to adapt WCF Data Service as Data Access Layer otherwise for server application where I am the only consumer , there is no point of going with Data Service ,in this case i would prefer to use EF is data tables are close to business model or else i would go for EF+Data Mapper>>Domain Model approach

    EF Vs LINQ

    1. EF - I would opt FE over linqtoSQL because of features and permanence , also EF has very good designer support .
    2. If difference between EF entities and business object are quite large then I would go for Data Mapper pattern to bridge the GAP.

    Hope it clarify 

    Ashwini


    Tuesday, July 3, 2012 5:21 AM