What way makes the most sense? I have a ASP.NET app... and maybe a Silverlight app in the future.. I want both to talk to web services..
At first, I like have the WCF project be by it self for the seperation..
But then I thought.. What is the point since I can just as easily have a 'WEBSERVICES' folder that contains all the .svc files and code in the EXISTING website project. ... Atleast that way.. deploying to a remote host will be a little easier since everything is in one project..
any other considerations ?
Why not have:
your WCF service and data contracts in a Contracts assembly
your WCF service implementations in a Services assembly
reference those two assemblies from your web site or web app
put the *.svc files into a WebServices directory
That way, you have
clean and nicely organized separation of concerns
the deployment files (*.svc) are in your web site / web app as you want
you can still extend / use your WCF code in other ways (e.g. self-hosting) later on without much fuss
Two things to consider:
Security - are your services only going to be used by your application, or do they have the potential to be used anywhere else (after all they are services). If so, you will be granting access to your application in order to grant access to your web services, or at least tweaking the access to that specific folder, which might lead to security breaches.
Deployment - If you do changes on your service that doesn't break the contract, in order to deploy the changes you will have to deploy the whole application.
I would prefer to go with the approach that Marc suggested (e.g. have an assembly for contracts, one for the service implementation) and have the webservice hosted as its own application and reference it from the ASP.NET app. This way, you have proper separation of concerns and can maintain both separately.
Related
I'm building an asp.net application that will be deployed on Azure. For the moment, I'm using regular asp.net: I'm building it in VS.
I have a web service that's in an asxm file MyService.asmx with a code behind file MyService.cs that calls a different class library called MyBigClass.cs that does most of the work.
If I want to prepare for a deployment on Azure in a few months and make that web service work in its own web role that I can scale based on usage load, should I put the classes that are in the MyBigClass.cs file into the MyService.cs file? The MyBigClass.cs file contains classes that are used for other parts of the application as well; should I remove these classes and only include the ones used by the web service?
Thanks.
Difficult to give a specific answer, and to be honest - I don't think the answer to this would be Windows-Azure-specific, but rather - this is simply a design best practice question, isn't it?
It comes down to how you will go about maintaining the application, and how you are going to manage versioning, but generally speaking - code that isn't shared does not need to get deployed to both roles, so either move it back with the 'parnet' solution (web app or service), or keep in a separate assembly which you will deploy with only the relevant role.
Code that is shared between the web app and service will exist in a shared assembly which you will deploy into both roles.
So you might end up with the following projects
A web site
An assembly supporting the web site
A Web service Service
An assembly supporting the web service
A shared assembly between the web site and web service
I hope this makes sense
First off, i'm fairly new to programming, I've built a few asmx web services but I am a little lost regarding how I should set up a WCF web service. I've tried to research this over the past couple days by reading through a lot of the documentation/articles/videos on MSDN but I'm still a confused.
Since my current web services are hosted on a separate box using IIS, from what I understand I need to create a WCF Library, then reference the Library in another WCF App and then host that app in IIS and reference the WCF App from my Front End? Seems like an extra step to me...? Not to mention a pain when developing on my local box.
Any advice or a point in the right direction would be very much appreciated. Thanks!
WCF gives you the option of sharing common assemblies (i.e. so both your service and clients can use the same domain model library), but it's not a necessary step.
You can host a WCF service through ASP.NET, same as ASMX. The "WCF Service Application" project template in Visual Studio configures it this way by default - as a WCF service hosted in IIS.
For the most common scenarios, it's really no different from ASMX. You create a WCF Service application, deploy it to a web server, and add service references in client applications. The importer will automatically generate classes for you, so you don't need to reference any assembly. No extra steps.
If you haven't already, you really should have a look through Microsoft's Tutorial. You'll find the steps very similar to those for setting up an ASMX-based architecture.
I'm working on building a set of ASP.NET (2.0) web-services to be deployed into a single web application under IIS7. The services will be added incrementally (over a period of a year or more) by multiple programmers. How should I organize my source in VS2005.
Should I use one project or several?
Should I use a Web-Application or Web-Site project.
How do I manage the web.config that they will all share.
Thanks for your advice.
Do you use source control now? All of your "control" problems are solved by any decent source control system (i.e., not VSS).
I'd put them into a single project assuming they have code and types in common between them. For instance, if they use the same data access layer and underlying database.
I would never use web site "projects" for web services. Any of their advantages are advantages for web sites made up of web pages, and not for the more complex requirements of web services.
I'll speak to how our shop handles this, which I find to work well.
We use several projects. One for each web service. This allows us to publish one service without effecting the others. We're also on VSS (bleck!) which makes for less conflicts.
We use a Web-Site project and it works fine
We manage the web.config by doing a diff on the file before we publish. The web.config's are something that rarely change
I have an asp.net 3.5 site and I've just written some wcf services. It is ok to just drop the .svc file right alongside my .aspx files or should I move my .svc files onto a separate virtual directory and IP and call it something like services.mydomain.com.
Just wondering what best practices are. Maybe it doesn't make any difference? I have a client app that will update the database that my web site uses. It updates through an IIS hosted wcf service.
IMHO it would be better to isolate the web service into a separate virtual directory and application pool. In this case the client application and the web service don't share the same AppDomain and if one fails the other will continue serving requests.
In our project we tend to keep them in separate virtual directories. I like to regard the service as something that can be used by more than one client, and so I like the deployment and hosting of it separate from the client. Of course, if you just stick it in a separate virtual directory you can argue to what extent the hosting is separated, but at least it is separate on a logical level, and easily moved to separate physical hosting if necessary.
You definitely don't want to have them in the same place - not least because it makes it hard to configure the appropriate level of security. It also makes configuration simpler as they won't share a web.config.
I have a Visual Studio solution containing a web site project plus a bunch of supporting projects (domain model, data access, etc).
I want to expose an API to the same underlying data, via urls under the same domain, so I developed a WCF/REST project to do this (which has dependencies on the same set of domain/data access projects).
Now I'm wondering what the pros and cons are of having the WCF service in a separate solution, deployed under a virtual IIS path, compared with just putting the WCF project into the original website solution.
Are there good reasons why I would want to go one way or the other? I'm not too experienced with IIS deployments.
IF you ever want to self-host the service instead of hosting it inside IIS, or if you ever want to share the service interface as an assembly for some reason, it will probably be easier to have it in a separate assembly.
I would recommend one assembly for the service interface(s) (including data contracts and such), one for the service implementation, and another (if needed) for a self-host (e.g. Windows NT service or command-line app). That's the cleanest separation and there's no real reason not to go that way, IMHO.
Marc