Reputation: 448
As software developers, we know "Dependency Inversion Principle" and "Separation of Concerns" is 2 main rule we should follow. Most of architectural patterns like "Clean Architecture" suggest some implementation details for us. But sample projects have some missing details. And i can not find a comprehensive solution.
My service solution has 3 project. These are:
As I understand, I can add reference from Infrastructure to Core. And from Api project to Core. Because, Infrastructure project has some implementation details and api project does not need to know that implementation details.
According to this:
Question 1: For database jobs, I can put an IRepository interface in Core project and I can implement this in Infrastructure project. But how can i register implementation types in Api project without adding reference to Infrastructure project?
Question 2: Logging is a kind of IO job. In my opinion, it should be in Infrastructure project. I want to use Serilog. I can abstract ILogger in Core project but it is not enough. For example, what should i do for "UseSerilogRequestLogging" middleware ? Or what should i do to add Serilog to generic host in CreateHostBuilder?
Recommended approach:
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
})
.UseSerilog();
Upvotes: 1
Views: 825
Reputation: 233150
I'm assuming that Service.Api is your application's entry point. That's where you put your Composition Root. The entry point references all dependencies in order to compose them. So, yes: Service.Api should have a reference to Service.Infrastructure.
The same goes for logging implementations, but keep in mind that logging is a cross-cutting concern best address with the Decorator pattern. You don't need an ILogger
interface in Service.Core. Adding one is a code smell, because logging isn't a Domain Model concern.
Upvotes: 3