Finally a reply
In my opinion you know you are doing something wrong (not the best way) when a method has 12 parameters. Hell… 4 is a stretch for me. Anything behind four should probably either become an array or separate application level object that is passed as a dependency with type hinting
At one time I felt very much the same way until I started implementing models as the fat and keeping controllers thin, which I assume you do as well based on our previous discussions. So its interesting you have not come across model API where the parameter list grows to unusual length.
Let me ask (while in general I agree with your assessment - models are my exception) how would you prefer to see things done? Also the parameters are passed to the model as associative array my framework handles the rest.
Breaking the workorder table into several distinct tables would result in more code and complexity. This table has been re-designed about 50 times since it's inception 2 years ago. Added to, removed, re-ordered, etc. Everything that is in there now is truly part of a workorder entity - right now (never know what the future holds) moving fields to another table does not make sense and does not align with what I have gathered from daily communication with the business experts of the company I work.
Although I can appreciate and understand your concern.
That said, the only direct dependency I see there is Application_Procedure_Model. In which case you could either pass an instance as a parameter or use a factory which exists inside a di container as a property of the object. To do that would either require delaying the construction phase until after all dependencies have been injected or passing the container to the constructor upon instantiation of whatever class this method belongs to.
I believe there are two dependencies - Procedure and Customer objects - the former is a web service and the later is being accessed externally in another DB until the time comes a RESTful API is also provided at which point both will be through REST.
After having read of various DiC's I am not entirely convinced that is what I need just yet. Rather my focus is on re-organzing my models so these monolithic massive objects can be broken into more logical units. Having read up on DDD lately I find myself compelled to experiment with the idea of aggregate root objects (which is what my model is now) but also implement aggregate sub objects possibly using a data mapper to fully abstract data access.
Ideally the single model class with a dependency on three tables should be refactored to a 1:1 relationship - the root object providing the API that exists now but the implementation for each being split into sub-models which are not accessible directly but only through the root object - which essentially delegates to sub-models.
This is where I understand the repository pattern comes into play? The repository will store root aggregates as a collection but may provide a declarative interface to the root objects which then delegate to the sub-models.
Each of the sub-models would implement their CRUD functionality and validations, etc. The relationships between objects would be handled by the root - and transactional operations could be bundled up into a Unit of Work. Sure this results in more classes but the code clarity would improve tremendously I think. I just am not totally clear on how or what to get started.
As an exercize - this is what I am thinking:
WorkOrder is the domain model - providing the API I currently have
Header is the entity of which you have seen the interface for - it contains information that is on every workorder printed.
There are about 20 other entities such as sequences, certifications, repairorders, reprocessess, additionals, cerilogs, etc
Each of these are models that require their own CRUD functionality and more but rely strictly on the existence of a workorder. Each of which I believe should be implemented as their own root aggregates and aggregate objects - according to my understanding of DDD nomenclature.
For instance repairorders is a header record which than has N number of line items dictating what needs to be done.
RepairOrderRoot would encapsulate at least two tables (repairorder & repairorder_item) both tables would ideally have their own CRUD model with validation and various finder methods. But neither should be accessible directly only being used indirectly through the RepairOrder root object - the root model. This model would also be responsible for handling the relationships. So when you query a repair order, you also get the line items returned to you if there are any.
Sorry for being so verbose but this topic confuses me and interests me and I have a great deal on my mind on how to best re-structure my fat models - following DDD patterns and principles - at least my current interpretation of them.
Love to hear more comments or experiences, fascinating subject