4

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.

Improve this question

1 Answer 1

Reset to default
4

In this case, CalcFoo() should take in an OsEarnDetailPoco. The method signature then becomes CalcFoo(OsEarnedDetailPoco data).

Services are typically injected in a DI architecture. Data is usually passed around through method calls.

Improve this answer
3
  • thanks for the reply. I guess i was always thinking constructor injection was the best for everything but i guess its just best for true dependencies and data should be passed in through the appropriate function. That makes a lot of sense.
    – coding4fun
    Jul 27, 2015 at 13:47
  • 3
    @coding4fun Whenever you start thinking "[Insert concept here] is the best for everything", that's the cue to take a step back and carefully analyze what your doing and why your doing it, or risk becoming a cargo cult programmer: en.wikipedia.org/wiki/Cargo_cult_programming. That said, DI is an insanely useful concept.
    – CurtisHx
    Jul 27, 2015 at 13:50
  • Let me ask one question though based on what you wrote. In most cases what you will be returning to client code is not Domain Objects (because it seems DO don't contain data) but Poco type classes? DO will only be used only be used for a variety of operations on those POCO type objects (like calculations). Does that sound about right?
    – coding4fun
    Jul 27, 2015 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.