Two developers are in a room with an executive. They're discussing a new project that will be developed with Angular and a .NET Core API. The project will be a complex data storage application with many HTML forms. The input data will be processed through validation and business rule layers before it is saved into a database. The data is ultimately displayed back to a report and sent to a customer.
Executive says: "I need to keep my costs low and it needs to be easy to support."
Developer 1 says: "All of our forms should be built dynamically. We can store form fields in a database and dynamically load them to a form at the time of rendering. That way, when you need to add a new field to the form in the future, do it yourself by visiting the admin section, picking the form, and adding it via configuration. That will be cheaper for you to support in the future."
Executive likes what is being said.
Developer 2 says: "Nice approach, developer 1, but all fields should be added via declarative HTML to their respective forms. By doing this, we have more control over our layout in our views. Also, with respect to our development approach, forms will POST data to endpoints with model binders at API endpoints who are expecting objects of a certain type. Those objects are then passed through validation and business rule layers who are coded to operate on the different attributes before the data is stored and ultimately sent to a report."
This is a real-world situation that I'm in now. By developer 1's approach, I am seeing the following issues:
- Loss of precise control over element positioning on HTML forms;
- Added complexity due to a dynamic approach;
- Demotion of the default model binder behavior and replacement with a rigged model binder using reflection to observe and bind POSTed form values;
-Loss of control over input validation and custom business rule processing;
Executive says "Yes, but this sounds like this might be harder to maintain"
I agree with Executive that development costs and the minimal costs related future maintenance need to be taken into consideration, but I don't agree with Developer 1's approach.
Had you been part of this conversation, what would you have said? Your input is appreciated. I'll be sharing it with my team!
What I have tried:
I've successfully developed applications for years. I am well-versed in using patterns and following recommended programming conventions.
This is an opinion-based question. Your feedback will be valuable for me as I back-up my opinions with your professional replies. Opinions will be shared with my team.
Again, this is opinion-based question. Thank you for your input/
Submit an article or tip