¿Es una mala práctica agregar System.Web en otros proyectos aparte de una página web?

Question

Estoy construyendo un arquetipo de proyecto web para mi empresa, la idea es tener como plantilla para comenzar a construir un nuevo proyecto con todo lo necesario ya hecho, seguridad, IoC, Logging, etc ...

I Estoy trabajando en el lado de la seguridad de la plantilla ... y al principio quería crear un proveedor de seguridad personalizado ... pero luego me di cuenta de que Microsoft ya lo hizo con la Membresía ... si algún proyecto necesitaría una proveedor ... solo tendrían que cambiar la web.config y eso es todo ...

Pero entonces viene mi problema ... Si quiero que las diferentes capas puedan obtener información de los usuarios ... Al igual que la capa de servicios (servicios comerciales ... no servicios web), necesitaría incluir System.Web y System.Web.ApplicationServices a esa biblioteca de clases.

¿Es eso una mala práctica? No quiero reinventar la rueda y el modelo de membresía de Microsoft es suficiente para mi escenario.

Gracias!

Answer 1

El hecho es que System.Web es parte de ASP.NET. Muchos métodos en System.Web hacen uso de HttpContext.Current, por ejemplo, que es el contexto sobre la solicitud HTTP actual. El uso de System.Web en una aplicación que no sea ASP.NET corre el riesgo de fallar de maneras extrañas porque tiene acceso a clases con métodos que pueden hacer uso de HttpContext. Esta es una mala idea; por lo tanto, a su vez también se debe considerar una mala práctica.

También está el intento de System.Web. Sí, es solo un ensamblaje y el IDE le permitirá hacer referencia prácticamente a cualquier ensamblaje que desee. Pero, la intención de System.Web es estar en el contexto de una aplicación ASP.NET. Eso es lo que los desarrolladores de Microsoft están asumiendo; entonces, lo desarrollarán bajo esa suposición. En el futuro, podrían romper efectivamente su aplicación debido a un cambio que beneficia las aplicaciones ASP.NET.Si eso sucede, no tiene ningún recurso para rediseñar su aplicación en respuesta a eso, no en un momento en el que realmente está planeando diseñar (o rediseñar) esta parte de su aplicación.

Answer 2

Sería una mala práctica para su capa de negocio usarla, ya que una capa empresarial debe ser independiente de la fuente de datos.

Por lo tanto, en su lugar, debe realizar solicitudes web en su (s) capa (s) de datos y simplemente exponer los datos recopilados a su capa empresarial o cualquier otro componente de autenticación según sea necesario.

Como regla general, todo lo que se encuentre en la capa empresarial que no sea estrictamente empresarial debe abstraerse en clases con una interfaz definida.

Answer 3

System.Web es una biblioteca como cualquier otra. Sí, contiene mucho código, no está incluido en el marco compacto y parte de su funcionalidad se está replicando fuera de él, por ejemplo, WebUtility es nuevo en .Net 4.5 y hace mucho de lo que hace HttpUtility. Sin embargo, es solo una biblioteca de clase.

Answer 4

Creo que no está nada mal. System.Web forma parte de .NET framework, por lo que estará disponible en todas partes donde .NET esté disponible. Utilizo System.Web en aplicaciones no web cuando necesito trabajar con html y el procesamiento de url.

Answer 5

Puede ser problemático ya que System.Web no es parte de .NET Framework Client Profile. Hacer referencia a esto requerirá que los consumidores instalen el paquete de marco completo. Probablemente esto no sea un problema si está creando una aplicación de servidor.

Referencia: Assemblies in the .NET Framework Client Profile

Answer 6

System.Web debe estar solo en su parte frontal. No en todas partes en tu arquitectura. El mejor ejemplo es lo que está sucediendo con Asp.Net 5, lo están eliminando. Al tener el componente web aislado en su capa frontal, evita modificar todas las capas de su arquitectura. Siempre debe intentar aislar el frente (web, web api, signalR, etc.) desde el medio (lógica de negocios, lógica de transformación, etc.) y el back-end (base de datos, Entity Framework, web api calls).