Skip to content

anton tishchenko

My feedback

1 result found

  1. 87 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    anton tishchenko commented  · 

    Let me explain more in details. Project is based on Sitecore.
    There are Helix Architecture principles https://helix.sitecore.net/

    Following them: solution can consist from projects on different layers:
    1) Foundation is core layer. It should be very stable and should not be changed often. Foundation projects could depend on each other
    2) Feature is intermediate layer. It contains separate modules features that can work independently. Feature projects could depend on Foundation projects, but not on other features.
    3) Projects is highest level. It should contain only specific code for website. It can depend on Features and Foundation projects. But could not depend on other Project.

    Following current NDepend report all is fine. All dependency principles are followed.

    But, there is dependency of Foundation and Feature projects from Project in reality. Interface is declared in Foundation, but implementation is in Project and registered via DI. It means that Foundation projects, that are core and stable part of solution, depend on Project level, which is not so stable and reliable.

    An error occurred while saving the comment
    anton tishchenko commented  · 

    Hi Patrick.

    I think it will be very useful feature. We have layered architecture: foundation, feature, project.
    Following current NDepend report, everything follows right dependencies. Project depends on feature and foundation. Feature depends on foundation. However due to some of DI registrations, we have complex dependencies. And sometime foundation level depends on project (in DI).

    That is why I would love this feature, it will allow to understand real dependencies.

    We are using LightInject, however we not always using it in this way:
    container.Register<IFoo, Foo>();

    We have wrapper under it, and major part of dependencies are registered by:
    registry.Register<Interface, implementation>();
    where registry is wrapper on container.

    So, my thoughts are that it would be nice, if dependency injection syntax to match would be configurable. (I understand that it adds complexity... And even without this configuration presence of this feature will be great)

    anton tishchenko supported this idea  · 

Feedback and Knowledge Base