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.