0

I am creating an Online Shopping Cart store. It is built through Net MVC Core.

There is a Front End View website: html, css, razor.

Then we have backend code design for Customers: including shopping cart, searching, buying orders, submitting orders.

Finally, there is backend for Vendors: vendors can submit their inventory, Products, and Supply Quantities which will be sent to online shopping place. This can be done with API calls or Flat files.

Currently everything is in 1 Solution. Is there any generally recommended practice for splitting into different solutions, or should I refrain? Should I separate the Customer Backend from Vendor backend? What is the general practice for different solutions and Nuget packages? I just started learning C#, and looking for basic guidelines, not sure where to start. Perhaps there is different flavors/methods of doing this.

0

Both methods have their advantages and disadvantages, and which one is better ultimately depends on multiple factors such as your team size and composition, your build and release setup, and what's more convenient for you.

Many projects just chuck everything into one solution, and for small- to medium-sized codebases worked on by a few people this is a perfectly fine approach. You get the convenience of being able to reference common code easily without messing with private NuGet feeds or cross-solution references, you don't need to switch between Visual Studio instances if the change you're making touches multiple solutions, and debugging is less of a pain. Judging by Microsoft focusing on things like lightweight solution load in VS2017 this is a pretty common use case.

In larger projects, however, the idea of having a single, tightly coupled repository of code with everything and the kitchen sink inside it requires a lot of communication and synchronization between the developers. If team Vendor Backend just changed your common library and needs to release their updated version yesterday, but team Customer Backend starts complaining that it'll take them a month to integrate the changes, that single solution becomes a problem.

You can rely on your source control discipline and proper branching to solve it, but at some point it becomes a good idea to split your project into smaller, independent components - for example, your utility methods could become a NuGet package, with a separate repository and solution, and a consistent versioning scheme. Then team Vendor Backend can update to the newest code in its own solution, and team Customer Backend can take its time working on integrating the newer package and other things they need to do without being held back.

If you're working alone and you don't have so much code that it becomes unwieldy to deal with a single solution, that's probably overkill. You trade away the convenience of just being able to change code and push things - if your common code is a NuGet reference, you need to change the code in the common solution, ensure it's up to snuff with respect to unit tests and standards, build and put it in the NuGet feed (presumably first the local one for testing, then the release one), update the package and only then have your change completed.

In short - if the benefits of loosely coupling your modules outweigh the drawbacks of having to maintain the strict release process, go for separate codebases for each module. If not, it's perfectly fine to just keep it in one solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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