Our product has two interfaces: a web interface (ASP.NET) and a service interface (WCF).
What is the correct way of connecting them to the business logic? Should the WebUI be just a client for the WCF service (see diagrams below)?
a. WebUI and WCF separated:
User1 -> ASP.NET -/-> Business Layer
User2 -> WCF ----/
b. WebUI is just a client of the service
User1 -> ASP.NET -/-> WCF -> Business Layer
User2 -----------/
If your service exposes absolutely everything that your Web Application needs to do, then why not use it!? ... If this service is going to be given to clients or similar, using it yourself is a great way to test/make sure it does everything you need.
I would encapsulate the Business Logic in a common DLL that both services will use.
In the service(IIS/WCF) handle only communication/protocol/serialization etc ....
This way it's easier to implement and performance is better.
This also depends on the architecture of your client. If you are using something like MVC, you may have the necessity to create large amounts of ViewModels. If your WCF services are granular, it may make sense to make the services return strongly typed DTO objects. If you share the DLL containing the service contracts with your client, you will be able to use the DTOs contained in the service responses as ViewModels. You get the advantage of scaling your UI application and your business logic middle ware differently by decoupling them in this way.
Related
I have worked with both technologies yet I’m about to build a new backbone services layer and thinking about WCF vs Web-Api.
The idea is to create a layer of services that will be consumed by both internal .NET components and by front applications.
The following are issues are not relevant to this case:
TCP, UDP
Proxy generator
WS-* standards like Reliable Messaging, Transactions
I'm considering about 2 approaches:
Web-api for app front application above n-tier WCF services
Web-api for app front and for a flexible services layer, thus avoiding HTTP hop between services
Our system is financial oriented, some services will operate as data services using the using some kind of OData and some will perform complex financial transaction (using complex types).
I've read about the new stuff that was recently added to Web-Api 2 and it seems to be a leading platform. I've Googled a lot about pros and cons and that WCF is still alive (or frozen).
A few of the relevant references:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
http://msdn.microsoft.com/en-us/library/jj823172.aspx
Under the assumption that all the services are on the same LAN and this is targeted to enterprise system, what would you recommend and why?
Here's the question... Do you need transport layer flexibility or are you fine with them being http(s) only services? If the services are HTTP-only and (as you say) you don't care about proxy gen and WS-* then I can't for the life of me think of a reason why you'd use WCF.
The programming model for REST / plain old http(s) is just so much leaner, the MVC "style" much more natural and not to mention that WCF can just get really complex really fast, makes me think that I would need a really good reason to choose WCF in 2013...
Not to throw a spanner into the works, but have you considered Service Stack:
https://servicestack.net/download
That's what I'd be using... (btw I'm not affiliated with them in any way / shape / form).
If you need multiple endpoints/transport protocols, or the ability for other applications to consume your services in .NET and work with them as you would any other referenced library (via web reference and a SOAP endpoint) the WCF should be your choice.
If you're looking for something lightweight and convention-based and/or you're looking to create a RESTful API, and HTTP(S) is an adequate transport, then Web API is the way to go. In this case, if you want the strong typing that you'd get with a SOAP web reference you'd probably be wise to write a reusable library that acts as middleware for consuming the services and providing data.
I am trying to decide which way to go. I have a solution that needs to have a web service and a client side which is a windows phone 7 project. the WP7 project needs to communicate with the database through the WCF service.
I am a little bit confused as to which way i should choose to go, and what are the differences, advantages/disadvantages of regular WCF service file VS the WCF Data Service.
Which way will be easier to go with considering my wp7 app needs to run queries on some tables on the database, nothing too fancy.
Any explanation will be welcomed.
Thanks
WCF Data Services are great if you need CRUD and flexible query capabilities - they allow you to expose underlying data (e.g. via Entity Framework) and control security with a minimum of development effort, as a RESTful API, especially to AJAX and SPA type client front ends. (Also, note that WebAPI now also offers similar capabilities).
WCF Services are more for Formal "Service" and "Operation" integration capabilities, where there is a lot more business focus, e.g. rules, processing, workflow, etc.
e.g. WCF would be useful to Submit a Claim for Processing (custom / rich graph of data input and output), Trigger a Nightly batch job (void response), etc.
Also, you can combine both technologies, e.g. for a CQRS type architecture, by using Data Services for the Query, and WCF for the Command type capabilities.
Where are web services typically found in three-tier architecture? What are some guildines for adding a new layer?
Web services usually, in fact, ARE middle tier. Client calling web services calling a storage (i.e. database) is a general pattern.
Well, if you go by the definition here, the webservice would be between the Business Access Layer and the Presentation Layer. It is simply a transport between the two layers. Your webservice could contain the Business Access logic but I don't think that is good design.
Well it depends, are you using them for Tier communication? are you setting up public facing web services? etc.
If you are using them for Tier communication they exist as inner layers at the tier level.
If you are making a public facing web service(as in out side of the application), then they are at the UI layer, depending on your needs this could be the same project as your UI or it's own.
You start by mixing up layers with tiers; they are not the same. You don't provide any information about your application which makes it impossible for people to answer you anyway.
I strongly recommend you to read some books about enterprise architecture; Fowler is a good author.
We have a few projects that we put all the data access in a separate web service project and the parent project will call the web service for everything data related. The web service will only accept connections from the web project server. My assumption is that the web service would be less susceptible to intrusion this way. I'm not really sure this is correct.
Is this more secure than just putting the data access in a class or dll within the parent project?
NOTE
Developers above me made this decision.
I don't see that as an effective way of securing your database. Of all the various ways that exist to protect your data layer, I don't think that moving calls from a class library to a web service is an effective way to protect yourself.
A better approach would be to make sure that you use parameterized queries or stored procedures to prevent SQL injection, and limit the privileges of your logins to only the operations that they need to perform.
However, there would be other arguments for having data access in a separate web service... such as re-usability, or a service-oriented architecture. If the same data access layer is needed from a variety of projects on multiple servers, by having the web service you wouldn't need to have the same class library duplicated all over the place... which would cause you to worry about which project has which version of your data access layer.
So, more secure? I don't think so... Other benefits? Probably...
Short answer: Yes
Longer answer: My assumption is that the web server that is exposing the services is behind its own firewall. Doing it this way insulates the database from intrusion by forcing hackers to go through another layer if they were able to compromise your application servers. Since the database connection strings do not exist on the app server, and a firewall prevents direct connections from that server to the database, the hackers would need to somehow puncture that firewall and gain access to the server that is hosting your data services.
Now, I also assume that the web services are not simply exposing methods like
execute(string sqlCommand)
if that's the case, then this solution might actually less secure than simply using a database without the web services. For this solution to truly be more secure you would want to create operation-specific methods on the web service server.
A DLL can't be accessed and executed from the Web, so far as I know. A Web service can. If that's true, the class library referenced by a Web project (or even a Web Service) is more secure than a Web service encapsulating that logic directly.
Further, there's the whole notion of Separation of Concerns. In my mind, data access logic belongs on a separate tier, completely separate from business logic. In a well designed architecture, Web services expose discrete methods that represent business transactions--not necessarily data transactions. Business transactions encapsulate one or more data transactions, which are represented by separate classes that encapsulate the data access logic and provide the security to ensure that SQL injection never occurs.
Others, naturally, may disagree. We're developers. It's our nature to disagree. :)
I am building an ASP.NET 3.5 Web Application which has the three standard layers (DAL,BLL and UI). I have to consume some third party web services and display the information on the UI. In which layer should I consume this web services and can you also point me to some good examples?
As is normally the case in questions like this, "it depends." It depends on what the Web Service is doing for you and whether you need to do anything else with the response when you get it. I'm guessing, however that it's giving you supplementary data to your BLL. In that case some Infrastructure service between your DAL and BLL might be a good place.
It's never a good idea to have your UI layer directly depend on a third-party service. What happens if it changes?
In this kind of situation I've generally regarded the third-party Web service as a similar resource to a SQL database, so I've wrapped it in its own layer which is then called from the business logic.
This makes it possible to map the Web service objects to my own domain objects. It also makes it easy to stub out the Web service for testing, and decouples my business logic from the third-party service.
In many cases its usually in the business or service layer. Usually several different combinations of MVC layers make calls into the service layer, and so the common functionality of a Web service should be found there.