Most of the examples i've see when watching anything on dependency management hit what i consider to be the holy grail in that the only dependencies on classes are interfaces that the IOC container can inject in. Of course most of the examples have to be trivial because of time constraints the presenter is under. Thats great for the client because they don't have to worry about hydrating classes but is that very real world? For example i'm working on a class has a variety of calculations. Here is the constructor:
public OsEarnDetail(IOsMacRateRepository macRates,IRate rate, OsEarnDetailPoco data)
_macRates = macRates;
_rate = rate;
_data = data;
As you can see, i have data structure which is going to prevent any IOC container from being able to hydrate the class automatically. Say this class has a complex function called
CalcFoo(). I not only have to calculate this value when a record is being retrieved/saved from the database. The results of this calculation need to be displayed to the user as the type a new entry (even before it get save to the database) and also recalculated if a user is changing any of the core data (again before it has been saved to the database).
Am i confused in any way or is there something wrong with the way in constructing my classes? I would think it would be common to have scenarios where you must run complex business logic even before it has been saved to the database and therefore you must hydrate your business objects with a set of data which would prevent your IOC container for being able to fully hydrate your dependencies.