Do they have the autonomy to deal with domain changes and refactor the current controller or API surface? Does the business work with the development team to prioritize tech debt? Are the developers disciplined? What does this mean to the API consumers? All very complex questions with no clear answers.īut is there a pattern we can embrace that directs us towards the pit of success? IMO the point which is most important in the workflow is when we decide where the action method goes. In the end this really does come down to how empowered your development team is.
#HACKERRANK PYTHON RUNNER UP SOLUTION CODE#
This means a higher cost for the business to maintain the code base. The velocity of adding new features and consistency of your API gets affected in the end. If the business isn’t willing to use resources to improve tech debt, then the developers quietly keep accepting the bloated nature of the controllers as inconvenient reality and move on. What started out as a simple problem now takes considerable thinking and refactoring to weed out. It often gets worse in proportion of how long the project has been running.
This snowball effect makes the controller boundaries really hard to reason with. Often new developers will look at the existing controllers, see a related feature and then chuck the new feature in there as well. The longer this keeps going on for, the harder it becomes to make decisions about the domain.
This is what we were trying to avoid but the controller ended up being a victim of circumstance. Your controller now does many things in the domain like some sort of god. The above takes little to no effort to do but over the long run your controller becomes bloated and fat. Why not write integration tests for this purpose?) (TBH I don’t see big value in controller unit tests anyway. If you have any controller level unit tests, this results in unnecessary dependencies (majority) requiring mocking when you’re trying to test a single action method. If you’re using dependency injection this usually means that the constructor signature keeps growing in size. This leads to further dependencies to the domain layer and mappers being introduced in the controller (aka coupling). The developers often take the path of least resistance/effort and use an existing controller when adding new features. Do you create a new one or do you reuse an existing one? This becomes doubly hard in the case of REST as you really need to understand your domain before you define your resources. It’s no longer easy to make a judgement call as to what controller your action methods should sit in. The code base is manageable.īut then your project grows and the domain evolves. So you end up doing some sort of mapping in the controller action method to transform the request parameters to a known type of view model as required. You have some sort of domain layer or a mediator that the request gets dispatched to. Typically in a greenfield project you start with clean a controller and has a few endpoints. The library referenced in this post SimpleEndpoints is hosted at. But why does it keep happening and how do we prevent it? What makes good developers fall into this trap?
This is a fairly simple problem to diagnose and most developers I speak to understand why this is an anti pattern. It’s the case of the fat/bloated/god controller.
I’ve been working with ASP.NET/CORE MVC and WebApi for a while now and there is a problem I often run in to. Preventing fat/bloated/god controllers by following a simple endpoint pattern
0 kommentar(er)
