CODEWITHSUNDEEP
c#.netclean-architecture
Dumitru Laurenţiu
Dumitru Laurenţiu

Reputation: 95

C# Clean Architecture - Best approach for creating abstractions

I've received different opinions on this topic so I decided to come here and ask the question. I have a relatively old codebase written on the .NET Framework that I must migrate to .NET 6 with Clean Architecture.

In the application layer I have a big messy helper class that uses lots of services and other classes with logic that are instantiated on the spot.

CacheService cacheService = new CacheService()

StepExecutor stepExecutor = new StepExecutor();

CacheInvalidator cacheInvalidator = new CacheInvalidator();

etc...

The implementation of those classes should now be moved to the infrastructure layer.

So, for the services I've created contracts in the application layer and moved the implementation in the infrastructure layer and I've injected them through the constructor of the gigantic helper class. All good.

My concern is for the other types of classes, some examples: manager, helpers, invalidator, executor, handler classes. ( CacheInvalidator, StepExecutor, WorkflowManager, EventHandler )

What is the best approach for adding an abstraction layer for these classes? Also make them as services and inject them trough the constructor? Should I use factories? Wrappers? I would highly appreciate any insight on this subject. Any opinion, any documentation. Personally, I think that this class should be entirely rewritten and split.

I'm really sorry if this is a really dumb question, I didn't manage to find a similar scenario as mine, most of the things I've found are only on small projects with 2 services where an abstraction layer is added and that's all. It's my first time doing something like this.

Thanks in advance and I hope this will maybe help someone in the future!

Upvotes: 2

Views: 1196

Answers (1)

plainionist
plainionist

Reputation: 3573

The first decision you will have to make for these other classes (managers, helpers, handlers, ...) is: which layer should this code go? Is it all about business logic? Then it should remain in the application layer and you can use those directly or though interfaces and factories.

Should those classes be considered as "infrastructure"? things you want to keep away from the business logic? then follow the approach you already described (interfaces in application layer, implementation goes to infrastructure layer).

Probably - not unlikely in legacy code bases - such classes tend to be "in the middle": some aspects could be considered as business logic, others as infrastructure. then u should take the effort and split the classes and then continue as described above.

Upvotes: 2

Related Questions