Séparation des problèmes et architecture à plusieurs niveaux dans ASP.NET 5 / ASP.NET Core 1

asp.net asp.net-core asp.net-core-mvc dependency-injection entity-framework-core

Question

J'ai du mal à trouver un moyen élégant de garder ma couche DAL distincte de ma couche MVC / UI dans ASP.NET 5 grâce au nouveau système d'injection de dépendance intégré que je souhaite utiliser.

Par exemple, j'ai un projet ASP.NET 5, un projet de couche de gestion et un projet d'accès aux données dans lequel j'ai plusieurs codes Entity Framework, tels que des entités et des contextes. dans ASP.NET 5 pour définir le contexte et cibler une base de données, la documentation principale suggère de procéder de la sorte dans la classe StartUp.cs.

services.AddEntityFramework()
    .AddSqlServer()
    .AddDbContext<BookContext>(options =>
    {
        options.UseSqlServer(Configuration.Get("Data:ConnectionString"));
    });

Cela signifie que je dois maintenant référencer mon DAL dans ce qui est fondamentalement ma couche d'interface utilisateur, ce qui, depuis des années, a toujours été une mauvaise pratique selon les différents experts et les billets de blog.

Une façon dont je travaille autour de cela est de créer deux nouveaux projets, l' un est un projet CompositeRoot qui contient des classes d'usine pour générer mes classes d'affaires qui accèdent ensuite à la DAL et aussi un projet Utilities avec une classe de configuration dans laquelle a un ConnectionString bien que je peut passer dans mon contexte, j’utilise ensuite le DI intégré pour tout relier et éviter de faire référence à mon DAL dans ma couche d’UI. Mais j'ai rencontré des problèmes avec la dernière version d'Entity Framework (version 7), car il ne semble plus possible de spécifier une chaîne de connexion dans le constructeur du contexte ou dans la méthode OnConfiguration . De plus, toute la documentation à ce jour ne semble pas du tout intéressée par ce mélange de préoccupations. Est-ce juste la façon dont nous faisons les choses maintenant? Confiance que les développeurs ne feront pas de "mauvaises" choses, comme référencer directement les classes DAL dans l'interface utilisateur? Ou y a-t-il un modèle que les gens utilisent pour garder les choses solides avec ce nouveau DI / configuration intégré pour ASP.NET 5?

Réponse populaire

Si vous demandez à 10 architectes civils de vous construire un pont, vous obtiendrez 10 architectures différentes. Pas un ne sera le même et aucun ne sera meilleur que l'autre.

Quels que soient le nombre de bonnes pratiques et de modèles de conception qu’ils appliquent, chaque architecte justifiera son idée. Certains seront trop zélés tandis que d'autres resteront simples et feront le travail. Entre autres choses, le budget, les dates de livraison et le savoir-faire auront un impact direct sur le type d'architecture que vous décidez.

La même règle s'applique aux architectes logiciels.

J'ai constaté que bon nombre d'architectes avaient les meilleures intentions du monde, mais comprenaient que la couche d'interface utilisateur dépend du DAL. Le raisonnement derrière cela est peut-être le suivant:

  • Ils n'y ont pas pensé
  • Ils ne s'en soucient pas vraiment
  • Cela facilite la DI puisque vous voyez chaque couche, ce qui facilite la mise en correspondance des interfaces avec leur implémentation.

De retour dans MVC 5, j'avais les couches suivantes:

-Contoso.Core (Class Library)
-Contoso.Data (Class Library)
-Contoso.Service (Class Library)
-Contoso.Web (asp.net MVC 5)
-Contoso.Web.Configuration (Class Library)

La couche Web.Configuration dépendait de Core , Data et Service . Cette couche est l'endroit où je configurerais mon matériel de DI.

La couche Web n'avait pas de dépendance vis-à-vis de la couche de Data et, pour commencer, j'utilisais le package de bootstrapper Nuget .

Peut-être que vous pourriez réaliser quelque chose de similaire avec ASP.NET 5

J'adorerais que Microsoft (ou quiconque) crée un modèle de projet fonctionnel plus adapté aux échantillons d'entreprise en utilisant une approche découplée ou même similaire à un exemple d'Onion Architecture.

En fin de compte, tout ce que je considère comme une architecture découplée raisonnable pourrait être trop pour certains, mais pas assez pour d'autres ...

N'hésitez pas à partager vos conclusions car je suis curieux de savoir comment vous avez réussi à le faire fonctionner.



Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi