• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

C# architecture

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    C# architecture

    Where I work we have one large repo which I am trying to split into smaller repos that are linked together.

    I was thinking of linking them using git submodules but that seems to cause other issues.

    Someone suggested using Nuget but I am not sure that will quite work as, at least for the time being, the code from the submodules needs to be built with the code from the main repo (it is all very heavily coupled). Am I a misunderstanding? Is this a use case for Nuget?

    Are there better technologies to use than git submodules for this?



    "He's actually ripped" - Jared Padalecki

    https://youtu.be/l-PUnsCL590?list=PL...dNeCyi9a&t=615

    #2
    Nuget is the way. I am not sure what your concern is, have you even tried this?

    Comment


      #3
      Not yet, I was trying git submodules.

      My concern was that Nuget seemed to be a way of bringing in libraries after they were built.
      I need to bring in the relevant version of code so it can all build together, be debugged together etc.

      Can Nuget do this? Information seems conflicting over it but most seems to imply not.
      "He's actually ripped" - Jared Padalecki

      https://youtu.be/l-PUnsCL590?list=PL...dNeCyi9a&t=615

      Comment


        #4
        How to get nuget to use source files rather than binaries

        Source Code Only NuGet Packages. NuGet Packages are the way how people… | by Attila Hajdrik | Medium

        merely at clientco for the entertainment

        Comment


          #5
          I'm tempted to say "you need to sort out the architectural issues in the code before you look at sub-modules Vs Nuget". Splitting what sounds like a single code-base (or tightly coupled mess of code-bases) can be done in one repo.

          Originally posted by MaryPoppins
          I'd still not breastfeed a nazi
          Originally posted by vetran
          Urine is quite nourishing

          Comment


            #6
            Originally posted by MyUserName View Post
            Where I work we have one large repo which I am trying to split into smaller repos that are linked together.
            , the code from the submodules needs to be built with the code from the main repo (it is all very heavily coupled).
            Git can be tricky enough without messing around with submodules / multiple repos. Things you might run in to... if you do a release all the repo's or submodules need to be tagged at the same time with the same version. If there's a bug down the line, you might need go back to a previous release, and branch all the repos and apply the fix to that version. Becomes a PITA.


            Comment


              #7
              I would look to use Nuget if the code is shared across multiple repo's, the ability to pull in or lock to a a specific version is a great feature.

              One thing that sprang to mind is when dealing with a monolithic code base that is being split into smaller repo's. Is the use of Sub Modules/Nuget the right choice? As your might really be trying to decouple in name and could be adding a an extra layer of complexity that is not justified.

              If you look to use a micro service architecture (especially if this is cloud/web based app) it may remove the need for tightly coupling the code base (you still need a deployment to fix a nuget package bug) and allow deployment of individual components as required.

              You could look to use a plugin architecture where the main program uses reflection to load the plugins from the sub project at run time. https://codeburst.io/dependency-inje...e-e579097c2f02
              Last edited by BlueSharp; 6 July 2021, 09:21.
              Make Mercia Great Again!

              Comment


                #8
                Originally posted by d000hg View Post
                I'm tempted to say "you need to sort out the architectural issues in the code before you look at sub-modules Vs Nuget". Splitting what sounds like a single code-base (or tightly coupled mess of code-bases) can be done in one repo.
                I agree that normally this would be the best approach but we have to split the repos out as we are beginning to release multiple products on different schedules so having them all in one along with the core code is causing bigger issues.
                "He's actually ripped" - Jared Padalecki

                https://youtu.be/l-PUnsCL590?list=PL...dNeCyi9a&t=615

                Comment


                  #9
                  Originally posted by BlueSharp View Post
                  If you look to use a micro service architecture (especially if this is cloud/web based app) it may remove the need for tightly coupling the code base (you still need a deployment to fix a nuget package bug) and allow deployment of individual components as required.
                  Microservices is definitely the direction I eventually want to head!
                  "He's actually ripped" - Jared Padalecki

                  https://youtu.be/l-PUnsCL590?list=PL...dNeCyi9a&t=615

                  Comment


                    #10
                    Originally posted by MyUserName View Post

                    I agree that normally this would be the best approach but we have to split the repos out as we are beginning to release multiple products on different schedules so having them all in one along with the core code is causing bigger issues.
                    Your issue there is that you seem to be currently trying to split a monolith application when you haven't identified what the common core / baseline application is yet (noting your point that the code from the submodules needs to be built with the code from the main repo (it is all very heavily coupled)).

                    The more I think about it the more I think you may be going about this the wrong way. You don't have a project with a number of submodules, you really have a number of separate projects all of which require a submodule containing the core code base.
                    Last edited by eek; 6 July 2021, 09:48.
                    merely at clientco for the entertainment

                    Comment

                    Working...
                    X