Utilizando ASP.NET Boilerplate sin inyección de dependencia (DI) Container?

Question

Irónicamente, el problema DI está tratando de resolver, es exactamente el problema que se ha creado en el proyecto. ¿Hay algún recurso para usar el marco donde soy capaz de escoger y elegir qué características quiero usar/enable y aquellos que quiero omitir? Es muy difícil gestionar las dependencias y desarrollar una aplicación modular y bien estructurada sin utilizar técnicas de inyección de dependencia. Con lo cual estoy muy en desacuerdo; y creo que es lo contrario, ya que hay muchos casos donde es común sin DI que con él. En la actualidad, estoy atascado en tratar de utilizar el proyecto llamando manualmente a todas las clases, ya que el DI está roto y constantemente propenso a errores, con excepciones vagas o implacables que se lanzan y evitar que la aplicación ejecute. No puedo depurarlo correctamente y a fondo, y eso no es el tipo de asistencia que estoy buscando. La pregunta que se plantea es, quiero usar el marco sin usando la inyección de dependencia, ¿hay soluciones; si es así, puedes proporcionarlas en forma de paso a paso, o copiar-paste? ¿Puedo usar el marco sin él, o estoy encargado de escribir mi propio porque es incapaz de mantener sus funciones modulares? Mi solución hasta ahora, es que estoy tratando de reestructurar, todo el marco para eliminar la lógica DI de la base del marco (se asocia dentro de funciones [root] en lugar de a su lado?); pero no estoy seguro de si hay maneras alrededor de ella, y si es posible simplemente no utilizarlo estrictamente si no quiero que esté habilitado. Ya he creado una clase de repositorio que se basa en la interfaz, entonces he hecho algunos cambios a algunas clases de gerente que usan el repositorio... pero luego hay tiendas, otros gerentes ( capas repetitivas apiladas entre sí), cache (no seguro por qué está capas en la fundación), UoW (no necesita esto, no puede anularlo), editores (no sé cómo resolver la lógica dentro de este grupo), Todo se siente más bien como una torre de Jenga, que un marco flexible donde el aislamiento de responsabilidades es el núcleo de la práctica del desarrollo. EDIT Related StackOver Problemas de flujo:Configuración de identidad AspNet Core3 Lo que he intentado:Múltiples identidades en ASP. NET Core 2.0ASP. Identidad NET sin Marco de Entidad¿Cómo resolver la interfaz genérica a la implementación genérica al usar la inyección de dependencia?Cómo implementar el patrón de unidad de trabajo con Dapper? (usado esto para hacer la interfaz Abp.UoW nullable, pero todavía hay otras áreas de lógica UoW forzada entre funciones en capas centrales de marco) Básicamente, cualquier resultado de búsqueda que contenga  sin dbcontext ,  sin marcos de entidad ,  sin inyección de dependencia ,  usando dapper , que todos contenían  identidad del asp  eran consultas de búsqueda que estaba utilizando. Antes de la modificación y después de las modificaciones (intente utilizar mis propios servicios de aplicaciones y modelo de dominio) todo cedió Se produjo un error al iniciar la aplicación. Aggregate Excepción: Algunos servicios no pueden ser construidos (Error mientras valida el descriptor de servicio 'ServiceType: Microsoft.AspNetCore.Identity... que es básicamente la interrupción de la inyección de dependencia, y no ser claro en lo que el problema es, además...  No puedes usar esta clase que hereda la clase de interfaz/abstract que se hace referencia en todo el marco y por DI.  Así que prefiero no usar DI, y trabajar a su alrededor, ya que las soluciones no son confiables para resolver mis problemas.

codemaestro · Accepted Answer

Espero que no suene a pedantic, pero su "sin el ejemplo DI" sigue siendo un ejemplo de DI. Usted aplica constructor de inyección, que es una forma de DI. Lo que entiendo es que quieres aplicar Pure DI en lugar de usar el Contenedor DI incorporado. Existen ventajas de usar el DI puro de usar un Contenedor DI, que es, por ejemplo, descrito en:

Cuándo utilizar un contenedor DI por Mark Seemann,
¿Cuándo deberías usar un contenedor? por mí,
y unos tres cuartos de nuestro libro sobre DI se centra en aplicar DI a mano, es decir, puro DI.

Ahora para las malas noticias...

Al trabajar con ASP. NET Core (y la mayor parte del marco que depende del .NET Core DI Container), usted puede nunca reemplazar por completo a DI Container con una opción Pure DI. Eso no debería ser un problema, sin embargo. Piensa en ASP. Container de NET Core como su sistema de configuración. Considere el sistema de configuración simplista de ASP. NET (clásico) MVC; su sistema de configuración consistía sólo en un diccionario grande. Aunque usted fue capaz de reemplazar los servicios en el diccionario, usted no podría eliminar el diccionario todos juntos. Estaba demasiado incrustado con el sistema. Lo mismo ocurre con ASP. Sistema de configuración de NET Core. Todo el marco depende completamente de su existencia. Y las posibilidades son delgadas que Boilerplate te permite trabajar sin ella.

Pero hay buenas noticias...

Aunque tú No puedo eliminar el sistema de configuración integrado, puede optar por aplicar Pure DI a sus propios componentes de aplicación y si lo deseas, incluso podrías volver a la vieja escuela apretada base de código si realmente quieres (que puedo ver de tus ejemplos que no, por suerte).

Cómo hacer esto con ASP. NET Boilerplate exactamente no puedo decir, por desgracia. Pero... muestras de código disponibles libremente de mi libro demuestra este concepto usando ASP. NET Core MVC Aquí. y especialmente Aquí..

Respondida el Dec 17, 2020 a las 05:42 - por codemaestro

Gpt · Answer

Entiendo que estás experimentando dificultades con la inyección de dependencia en ASP.NET Boilerplate y estás considerando trabajar sin utilizar un contenedor de inyección de dependencia. Aunque ASP.NET Boilerplate promueve el uso de inyección de dependencia para facilitar la gestión de dependencias y el desarrollo de aplicaciones modulares, es posible utilizar el marco sin depender de un contenedor de inyección de dependencia.

A continuación, te proporcionaré algunos pasos generales que puedes seguir para intentar trabajar sin un contenedor de inyección de dependencia en ASP.NET Boilerplate:

Eliminar dependencias de inyección de dependencia: En tu aplicación, trata de eliminar las dependencias en las clases donde no las necesites. En su lugar, puedes utilizar un enfoque más manual, como crear instancias de las clases necesarias directamente en el código.

Instanciar clases directamente: En lugar de depender de la inyección de dependencia para resolver las dependencias, puedes instanciar las clases directamente en el código donde las necesitas. Por ejemplo, en lugar de inyectar un servicio en un constructor, puedes crear una nueva instancia del servicio donde lo necesites.

Gestionar manualmente las dependencias: Puedes crear tu propio mecanismo para gestionar las dependencias y resolverlas manualmente cuando sea necesario. Esto puede ser más laborioso que utilizar un contenedor de inyección de dependencia, pero te da más control sobre cómo se resuelven las dependencias en tu aplicación.

Reestructurar la lógica de tu aplicación: Si estás teniendo dificultades para trabajar sin inyección de dependencia, puedes considerar reestructurar la lógica de tu aplicación para minimizar la dependencia de las clases externas. Trata de diseñar tus clases de manera que sean más independientes y requieran menos dependencias externas.

Es importante tener en cuenta que trabajar sin inyección de dependencia puede hacer que tu código sea menos flexible y más difícil de mantener a largo plazo. La inyección de dependencia es una práctica recomendada en el desarrollo de software, ya que ayuda a mejorar la modularidad, la extensibilidad y la testabilidad de las aplicaciones.

Espero que esta información te sea útil y te ayude a abordar tus problemas con la inyección de dependencia en ASP.NET Boilerplate. ¡Déjame saber si tienes alguna otra pregunta o si necesitas más ayuda!

Respondida el Dec 18, 2020 a las 05:43 - por Gpt

Gemini · Answer

Entiendo tu frustración con la inyección de dependencias (DI) en el marco ASP.NET Boilerplate. Aquí tienes algunas opciones para utilizar el marco sin DI:

Opción 1: Crea tus propias clases de servicio

Puedes crear tus propias clases de servicio que implementen las interfaces necesarias y las registres en el contenedor de servicios manualmente. Por ejemplo:

csharp
public class MyService : IMyService
{
    // Implementación de los métodos de la interfaz
}

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton();
}

Opción 2: Utiliza un contenedor de DI de terceros

Puedes utilizar un contenedor de DI de terceros como Autofac o Simple Injector para registrar tus dependencias. Esto te permitirá utilizar la inyección de dependencias sin depender del contenedor de DI integrado de ASP.NET Boilerplate.

Opción 3: Reestructura el marco

Puedes reestructurar el marco para eliminar la lógica de DI de la base del marco. Esto implicaría eliminar las clases de registro de DI y reemplazarlas con un mecanismo de registro manual.

Consejos adicionales:

Utiliza clases estáticas o variables singleton para almacenar las dependencias necesarias. Evita utilizar clases abstractas o interfaces para las dependencias, ya que estas están estrechamente acopladas con el contenedor de DI de ASP.NET Boilerplate. Sé consciente de las implicaciones de rendimiento de la inyección manual de dependencias.

Conclusión:*

Es posible utilizar el marco ASP.NET Boilerplate sin DI, pero requiere un esfuerzo adicional y una comprensión profunda del marco. Te recomiendo explorar las opciones anteriores y elegir la que mejor se adapte a tus necesidades.

Respondida el Dec 18, 2020 a las 05:44 - por Gemini

Utilizando ASP.NET Boilerplate sin inyección de dependencia (DI) Container?

3 Respuestas: