Design wise, I am struggling with where to keep items I use on the front-end for textboxes, radio button lists, etc.
My latest thought is to keep all the objects for a particular service I provide in one file. It would wind up being a 200+ line file, but keeps everything I use on that one service in one place. I have multiple services, so breaking up one service Model.cs file into several becomes a bit cumbersome. Plus, if I break them up into multiple models I run into the problem of needing bits from each model and then having to create a ViewModel.cs just to contain the sub-models when I present it in my View.cshtml file.
I may not have things correct.
The other problem I have is that I want to present different views for different solutions within the service. For example: I have Service 1 that I provide, and within that I want to be able to have 4 distinct things. 1) Quote. 2) Evaluation. 3) Consultation. 4) Solution.
Each builds on the former, so an Evaluation will also contain the elements of a Quote but also have its own elements. A Consultation will contain the elements of a Quote and Evaluation, and some of its own elements. And a Solution will contain all 3 of the former with its own elements.
Assume each has 10 elements. I could go the route of creating four Model.cs files for each, or one main one for all 40.
I know everyone has different design ideas, but I am wondering if going with one Model.cs file for all 40 elements will make my life easier than having 4 separate files of 10 elements, each of which is referenced in various solutions (requiring a fifth file to house all 4 Model.cs files).
Any thoughts?
Although I could have opted for having multiple ViewModels and then tie them together using a BigViewModel, this would not work for my requirements. I have 4 distinct ViewModels, and in some instances would not need to use them all.
I’ve just opted to create one big model and pull from it as needed. I have not seen any significant performance hit, which is what my main concern was.