Is Adding System.Web on other projects than a web page a bad practice?

Question

I'm building an archetype of web project for my company, the idea is to have like a template to start building a new project with everything necessary already done, security, IoC, Logging, etc...

I'm working on the security side of the template... and at the beggining I wanted to make a custom security provider... but then I realized, that Microsoft already did that with Membership... if any project would need a different provider... they would only need to change the web.config and that's it....

But then it comes to my problem... If I want the different layers to be able to get users information... like the services layer (business services... not web services), I would need to include the System.Web and System.Web.ApplicationServices to that Class Library.

Is that a bad practice? I don't want to re-invent the wheel and the Microsoft Membership model is enough for my scenario.

Thanks!

Answer 1

The fact is that System.Web is part of ASP.NET. Many methods in System.Web make use of HttpContext.Current for example--which is the context about the current HTTP request. Using System.Web in a non-ASP.NET application runs the risk of failing in odd ways because you have access to classes with methods that might make use of HttpContext. This is a bad idea; so, in turn should also be considered a bad practice.

There's also the intent of System.Web. Yes, it's just an assembly and the IDE will let you reference pretty much any assembly you like. But, the intent of System.Web is to be in the context of an ASP.NET application. That's what the developers at Microsoft are assuming; so, they will evolve it under that assumption. In the future they could effectively break your application due to a change that benefits ASP.NET applications. If that happens, you have no recourse to be redesign your application in response to that, not at a time where you're really planning on designing (or redesigning) this part of your application.

Answer 2

It would be bad practice for your business layer to use it, as a business layer should be data source independent.

So you'd instead make any web requests in your data layer(s) and just expose the gathered data to your business layer or any separate authentication components as necessary.

As a rule - anything in your business layer that isn't strictly business needs to be abstracted out into classes with a defined interface.

Answer 3

System.Web is a library like any other. Yes, it contains a lot of code, is not included in the compact framework and some of its functionality is being replicated outside it, for example WebUtility is new in .Net 4.5 and does much of what HttpUtility does. However, it is just a class library.

Answer 4

It may be problematic since System.Web is not part of the .NET Framework Client Profile. Referencing it will require consumers to install the full framework package. This is probably not an issue if you're building a server application.

Reference: Assemblies in the .NET Framework Client Profile

Answer 5

System.Web should be only on your front end. Not every where in your architecture. The best example is what is going on with Asp.Net 5, they are removing it. By having having the web component isolated to your front end layer, you avoid to modify all layers of your architecture. You should always try to isolate the front (web, web api, signalR, etc) from the middle (business logic, transformation logic, etc) and the backend (database, Entity Framework, web api calls).

Answer 6

I think that it's not bad at all. System.Web is a part of .NET framework so it will be available everywhere where .NET is available. I do use System.Web in non-web applications when I need to work with html and url processing.