[ASP.NET] - Project Structure & Package Manager
How do you organize your folders and files? Should you split things into several sub-projects? Should you use a package manager?
In this part I’ll lay out my personal experience with organizing and managing projects, and using a package manager
1. Project & Solution
The easiest and simplest way is to have only 1 project. In Part 1 you also got “experience” typing the command to create a project.
Visual Studio isn’t like that: it forces you into a concept called the “Solution”. With it, one or more projects live inside 1 solution. When you open a project created by the dotnet new * command in Visual Studio, it also creates some throwaway Solution and stuffs your project into it.
It’s a good habit to create several projects for different purposes, serving your software project in general and ASP.NET in particular
1.1. The reasons
You wonder why you should split into so many projects? Wouldn’t keeping it all together save a ton of library-including work?
1.1.1. Reuse
When some code with its own distinct purpose gets split into its own project, it becomes very easy to reuse in other projects.
Say you have some helpers and classes that make connecting to a database fast and tidy. When it’s in its own project, you can easily push it to git, and other projects just clone it and use it. When you update that project on git, all of its clones get updated too.
1.1.2. Distribution
Same example: your project is now at the library level, that is, it’s a library. You can lure your friends into using it, developing it further, contributing to it, packing it into a nuget package, blah blah blah and blah blah blah
1.1.3. Deployment
Some company finds version 1.0 of your lib really nice and decides to download it and use it in their monstrous project. 10 years later you update your lib to version 2.0, reusing all the existing methods and functions, just changing the algorithm to make it run faster. The company only has to spend a minimal amount of effort to clone your lib, build it and replace the lib running in their production. Done. No need to rebuild the whole project, no need to redeploy.
1.1.4. You name it
The longer you stay in the coding trade, the more other benefits of this splitting you’ll discover.
1.2. Splitting projects
In the MVC pattern, Model-View-ViewModel are all tied together, so we don’t split them
That said, some companies split the Model into its own project. This makes managing the code easier. Sometimes they split the Controller into a project too
One rule I often use for splitting projects is based on its purpose. For example:
- Unit Test -> split
- Data Connection Layer -> split
- Encryption / Decryption -> split
- Encryption on its own -> do NOT split
2. Package Manager
Building a website has 2 parts, front-end and back-end. And both parts have a package manager (with ASP.NET)
2.1. For backend - NUGET
On the backend, the benefit of using a package manager (nuget) is way too obvious. You just “search & install“ — no more sitting up late at night fiddling with cracking IDM to download some .dll library, then rummaging through the downloaded files to import it into the project.
It also wipes out the platform compatibility problem with libs (a lib built for x64 only runs on x64, and likewise for x86)
2.2. For front-end - Yarn
Bower is no longer supported
What about the front-end? Doesn’t the site run just fine by adding the .css and .js files?
that’s right, BUT
- the sources aren’t consistent
- this lib depends on that lib, that lib depends on the other one
- it works on my machine, so why doesn’t it work on another machine
and front-end package managers were created to solve these problems
So, where ASP.NET has only 1 (a few) package manager like Nuget, in the front-end world we have a dozen. I’ll briefly introduce a newly rising rookie that is very hot right now - YARN
2.2.1. Dependencies
JQuery is a very popular lib, and a billion other libs are built needing it. But JQuery has quite a few different versions, and different libs use different versions of JQuery.
Yarn removes this problem for you. When JQuery is installed through Yarn there is only 1 version, and every other package builds on that version.
2.2.2. Sources
Since all the packages are hosted on yarn, you just get them from Yarn and you’re done — no going to each lib’s website hunting for the download button.
2.2.3. Reproducibility
Yarn uses a package.json file to store the information about the installed packages. Using this file, on any machine, it produces exactly the files your project needs to run just as nicely as it did during development
That’s it ;)