A
Allan.Iverson
I'm responsible for helping .NET developers at a Fortune 100 company and I
have a general question. Recently a team of .NET developers created a
intranet WPF Browser application and 4 distinct WCF services that support
requirements of that application. Each WCF service has multiple web methods
and overall each service appears to be a coherent entity from a functional
perspective.
However the team implemented all four services in a single Visual Studio
2008 project. So that project has four .SVC files, four managed assemblies,
four unique service contracts and a single shared web.config for storing
bindings, endpoints, etc. While technically this should work fine it's not
the way that I would have structured the overall projects solution. Note: We
host all of our WCF services in IIS 6.0, and will be moving soon to IIS 7.0.
We also have in place an automated build and deployment process that
basically was architected to deploy each Visual Studio Web Type project to
it's own virtual directory, so seperating the services during deployment is
not something we can easily do.
Here are some of the drawback I see to this approach:
1.) Multiple .SVC files precludes specifying a default document to be served
up when clients browse to the services virtual directory.
2.) As our .NET IIS deployment standard calls for creating a specific
application pool for each virtual directory, having multiple WCF services in
the same virtual directory needlessly couples the services, should one
service misbehave, and we have to recycle the app pool.
3.) Having a single web.config file governing four WCF Services, by
necessity is more complex, than having a single web.config file for each
service. This would increase the chances that a misconfiguration in this file
would affect four services at runtime as opposed to only one. We could
mitigate the clutter by sourcing into the web.config seperate stanzas for
each specific web service configuration but that still doesn't remove the
runtime dependencies forced by a single web.config file.
While I certainly don't think this approach would be even close to a 'Best
Practice' I'm reluctant to force the team to refactor each WCF service into
it's own individual project.
I'm looking for any comments or insights members can supply to help me make
a more informed decision.
have a general question. Recently a team of .NET developers created a
intranet WPF Browser application and 4 distinct WCF services that support
requirements of that application. Each WCF service has multiple web methods
and overall each service appears to be a coherent entity from a functional
perspective.
However the team implemented all four services in a single Visual Studio
2008 project. So that project has four .SVC files, four managed assemblies,
four unique service contracts and a single shared web.config for storing
bindings, endpoints, etc. While technically this should work fine it's not
the way that I would have structured the overall projects solution. Note: We
host all of our WCF services in IIS 6.0, and will be moving soon to IIS 7.0.
We also have in place an automated build and deployment process that
basically was architected to deploy each Visual Studio Web Type project to
it's own virtual directory, so seperating the services during deployment is
not something we can easily do.
Here are some of the drawback I see to this approach:
1.) Multiple .SVC files precludes specifying a default document to be served
up when clients browse to the services virtual directory.
2.) As our .NET IIS deployment standard calls for creating a specific
application pool for each virtual directory, having multiple WCF services in
the same virtual directory needlessly couples the services, should one
service misbehave, and we have to recycle the app pool.
3.) Having a single web.config file governing four WCF Services, by
necessity is more complex, than having a single web.config file for each
service. This would increase the chances that a misconfiguration in this file
would affect four services at runtime as opposed to only one. We could
mitigate the clutter by sourcing into the web.config seperate stanzas for
each specific web service configuration but that still doesn't remove the
runtime dependencies forced by a single web.config file.
While I certainly don't think this approach would be even close to a 'Best
Practice' I'm reluctant to force the team to refactor each WCF service into
it's own individual project.
I'm looking for any comments or insights members can supply to help me make
a more informed decision.