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

6

8

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!

Kimbell answered 11/9, 2012 at 13:18 Comment(0)
R
5

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.

Refrigerant answered 11/9, 2012 at 14:17 Comment(1)
I do understand that, but how can I expose my authentication membership provider in a way that is transparent for both my Front end project and my Business Layer? For example... in some case I would want to allow or deny some method based on user roles... Authorizing via Authorize on the controller won't be enough.Kimbell
M
1

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.

Maxiemaxilla answered 11/9, 2012 at 13:31 Comment(2)
What about System.Web.Mail (pre .NET 2.0). You want your BL to send emails, not your UI.Silicium
Again the business layer shouldn't be implementation specific, so you'd abstract it out to another class with a standard interface. Updated my answer.Maxiemaxilla
F
0

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.

Flipflop answered 11/9, 2012 at 13:37 Comment(1)
@Refrigerant I think that statement is a generalization and, therefore not true in every situation. If the business layer deals with web matters, for example, it may be a good choice.Flipflop
B
0

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

Bonesetter answered 11/9, 2012 at 13:53 Comment(1)
Please note that the .NET Framework Client Profile has been discontinued starting with .NET 4.5.Bunni
A
0

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).

Aristippus answered 12/1, 2015 at 16:27 Comment(0)
A
-1

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.

Advisedly answered 11/9, 2012 at 13:42 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.