C# 在网页以外的其他项目上添加System.Web是一种糟糕的做法吗?

C# 在网页以外的其他项目上添加System.Web是一种糟糕的做法吗?,c#,asp.net-mvc,system.web,C#,Asp.net Mvc,System.web,我正在为我的公司构建一个web项目的原型,其想法是像一个模板一样开始构建一个新项目,所有必要的事情都已经完成,包括安全性、IoC、日志等 我正在模板的安全方面工作。。。在beggining我想做一个定制的安全提供商。。。但后来我意识到,微软已经通过会员制做到了这一点。。。如果任何项目需要其他提供商。。。他们只需要更改web.config,仅此而已 但后来我的问题来了。。。如果我希望不同的层能够获得用户信息。。。与服务层(业务服务…而不是web服务)一样,我需要将System.web和System

我正在为我的公司构建一个web项目的原型,其想法是像一个模板一样开始构建一个新项目,所有必要的事情都已经完成,包括安全性、IoC、日志等

我正在模板的安全方面工作。。。在beggining我想做一个定制的安全提供商。。。但后来我意识到,微软已经通过会员制做到了这一点。。。如果任何项目需要其他提供商。。。他们只需要更改web.config,仅此而已

但后来我的问题来了。。。如果我希望不同的层能够获得用户信息。。。与服务层(业务服务…而不是web服务)一样,我需要将System.web和System.web.ApplicationServices包含到该类库中

这是一个坏习惯吗?我不想重新发明轮子,微软的会员模式对我的场景来说已经足够了


谢谢

对于您的业务层来说,使用它是不好的做法,因为业务层应该独立于数据源

因此,您可以在数据层中发出任何web请求,并根据需要将收集的数据公开给业务层或任何单独的身份验证组件


通常,业务层中任何非严格意义上的业务都需要抽象为具有定义接口的类。

System.Web与其他库一样是一个库。是的,它包含大量代码,不包含在紧凑型框架中,并且它的一些功能正在其外部复制,例如,它在.NET4.5中是新的,并且做了很多事情。然而,它只是一个类库。

我认为它一点也不坏。Web是.NET framework的一部分,因此它将在.NET可用的任何地方都可用。当我需要处理html和url时,我会在非Web应用程序中使用System.Web

这可能有问题,因为System.Web不是.NET Framework客户端配置文件的一部分。引用它将要求使用者安装完整的框架包。如果您正在构建服务器应用程序,这可能不是问题


参考资料:

事实上,System.Web是ASP.NET的一部分。例如,System.Web中的许多方法都使用HttpContext.Current,这是关于当前HTTP请求的上下文。在非ASP.NET应用程序中使用System.Web有以奇怪方式失败的风险,因为您可以使用可能使用HttpContext的方法访问类。这是个坏主意;因此,反过来也应被视为一种不良做法


这也是System.Web的意图。是的,它只是一个程序集,IDE可以让您引用几乎所有您喜欢的程序集。但是,System.Web的目的是在ASP.NET应用程序的上下文中。这是微软的开发者们的假设;所以,他们会在这个假设下进化。将来,由于ASP.NET应用程序受益的更改,它们可能会有效地破坏您的应用程序。如果发生这种情况,您就没有办法重新设计应用程序来应对这种情况,而不是在您真正计划设计(或重新设计)应用程序的这一部分时。

System.Web应该只在前端。不是架构中的每个地方。最好的例子是Asp.NET5正在发生什么,他们正在删除它。通过将web组件隔离到前端层,可以避免修改体系结构的所有层。您应该始终尝试将前端(web、web api、Signal等)与中间(业务逻辑、转换逻辑等)和后端(数据库、实体框架、web api调用)隔离开来。

关于
System.web.Mail
(2.0之前的版本)呢。你希望你的BL发送电子邮件,而不是你的UI。同样,业务层不应该是特定于实现的,所以你应该用标准接口将其抽象到另一个类中。更新了我的答案。@dexpert我认为这是一种概括,因此并非在所有情况下都是正确的。例如,如果业务层处理web事务,它可能是一个不错的选择。请注意,.NET Framework客户端配置文件已从.NET 4.5开始停止使用。我确实理解这一点,但如何以对前端项目和业务层都透明的方式公开身份验证成员资格提供程序?例如在某些情况下,我希望根据用户角色允许或拒绝某些方法。。。仅通过控制器上的授权进行授权是不够的。