Frameworks don't solve problems, they just give you new ones to solve. Isolate your team and sanity by delaying them as much as possible. When you decide to add one, make it a plug-in that you can swap out.
For every framework in your project the following occurs:
- You are married to an implementation that you have little to no control over.
- It's one more thing that you or your team "has to know".
- It's one more thing you have to explain to a junior.
- You still own the code, clients don't care where the bug is.
- Your project is that much more complicated.
Here's a challenge for you, start a new project, and see how far you can go without adding a single 3rd party framework or library. (Just don't write your own JSON parser or secure hash algorithm, that's probably a bit too far.)
Don't use a database to start, just keep data in memory or parse to a file.
Focus on your domain and use cases, nothing else matters.
Set yourself up to make all your future frameworks a plug-in that you can swap in and out at will. You can do this by...
- Putting everything behind an interface.
- Standard old repository pattern for data access.
- Avoid any framework specific implementation that would break code if removed.
- Keep your client interface (REST, RPC, ect.) as thin as possible. (I.E. No logic in controllers.)
- Don't marry yourself to any one implementation, frameworks aren't your spouse; you don't need to be faithful to anything.
Remind yourself boring is beautiful.
I have been doing the following in my .NET projects:
DI Framework - Write your own factories. You'll understand your dependency chains and it will make you question if you really need all those layers of abstraction. Hint: In .NET Core, you can manually add a ServiceDescriptor directly into the IServiceCollection and get the best of both worlds.
AutoMapper - Write your own mapping code. It won't kill you. Enforce correctness via constructors. If your parameter names match, Intellisense/ReSharper will fill in the parameters for you.
Moq - Push logic down from handlers/services/managers into your domain. Make everything a function call in your application services. You don't need to verify that a function was called.
Queries - Apply extract method to your LINQ queries into static methods that return lambdas and expressions, these are super easy to unit tests.
Logging - Format a string, write it to a file.
FluentValidation - Use the built in attributes, write your own validation attributes if needed.
I have found that applying this mode of thinking has turned me into a better developer by increasing code quality and velocity while reducing the number of lines of code I have to write. Divorcing yourself from frameworks, or putting them off until the last possible moment is freedom for yourself and your team.
This is not to say that one should be "anti-framework", but just aware of what you are getting into when you decide to add one. NuGet makes it very easy these days just add something to a project. When you decide to bring one into your project, keep it isolated to the point where you can easily remove it and replace it with something else should you wish.
Haven't created your DEV account yet?