dotnet
Consider removing global usings for namespaces within the eShop repo
As a sample project especially, I think explicitly including the usings for eShop.* namespaces would help to improve the readability of the project.
Happy to make this change if the team is open to it!
@erinnmclaughlin Thanks for opening this issue and sharing your feedback!
We were hoping to show the benefit that GlobalUsings can give when reducing the big blocks of using at the top of source files.
Are you thinking that including the usings explicitly might make it easier for people to explore the relationships between types in the codebase?
@captainsafia Thanks for the response! Seems like there are two similar-but-different issues here: one about global usings in the context of navigating this codebase specifically, and one about global usings in general. I added some thoughts about each below. Let me know what you think!
Are you thinking that including the usings explicitly might make it easier for people to explore the relationships between types in the codebase?
This was my initial thought, yes. For these "reference" repositories especially, I think many developers are probably browsing the codebase directly through GitHub, rather than cloning it & browsing with an IDE. GitHub has a much more limited “go to definition” feature than, say, Visual Studio, which can make it harder to casually follow some execution path from point A to point B. I ran into this when initially browsing the repo, so thought it was worth mentioning!
We were hoping to show the benefit that GlobalUsings can give when reducing the big blocks of using at the top of source files.
This makes sense, but I'm also wondering how selective to be about which namespaces should / shouldn’t be added to a project's global usings? While I can see the value of simplifying source files, I worry that being too casual about global usings can make it harder to manage a project's dependencies. Do you see this as a potential issue?
My current thought is that global usings should generally be limited to frequently-referenced namespaces that are truly core dependencies of the project (like MediatR in Ordering.API for example), or namespaces that are "built-in" to an already-core project dependency (I don't see much of an issue with globally including System.Text.Json, for example).
Definitely curious to hear your thoughts about this!
Thanks for sharing your thoughts here.
Although I'm a bit entrenched in the codebase at the moment (😅 ) I do see your point that the excessive use of global usings for project-specific namespaces makes it harder to understand the relationships between projects in the code.
Your proposal that global usings should be limited to core dependencies and built-in libraries makes sense. It would also make sense to me that namespaces for other assemblies are not included in global usings.
To me, that strikes the balance between allowing you to see what dependencies projects have with each other without polluting each file with namespaces in its own scope. For example, the WebApp/GlobalUsings.cs would change as follows:
global using eShop.WebApp.Components;
global using eShop.WebApp.Services;
global using eShop.ServiceDefaults;
- global using eShop.EventBus.Abstractions;
- global using eShop.WebApp.Services.OrderStatus.IntegrationEvents;
- global using eShop.Basket.API.Grpc;
So it's clear in the code that it takes a dependency on the Basket API and order processing layer.
If that makes sense to you, I'd be happy to review a PR.
@SrushtiPasari94 can you coordinate with @captainsafia here and propose changes per project
