These are my notes on C# which is Microsofts server side language. By server side language this is a programming language that you can use to create applications that run on a web server. There is more to C# than this but for the sake of the notes I am preparing I want to focus on using C# as a server side language.
The recommended or future approach is to use the .NET core framework for building applications if you are aiming to build a cross platform (runs on linux) web site. The .net core framework is the better way of building web sites as it is the latest iteration of the .net frameworks and has been written from the ground up to be specifically designed for web sites. The .net framework (not core) is designed for more general usages such as building desktop applications. It is possible to mix and match the two by using a microservices architecture and communicating between the two using RPC’s (remote procedure calls).
When learning a new technology stack my advice is to try and learn it from the ground up by reading examples and using the command line interface rather than using the Visual Studio IDE. The reason for this is that this will give you a much more comprehensive knowledge of the framework you are dealing with plus it should encourage you to automate as much of the development process as you can once and to automate these processes early.
What I would suggest you do first is to come up with a basic architecture for your web site and to then set up source code control and a build script to establish a development environment. Not forgetting of course the all important install.sh script that will set up the local development environment on another developers PC. In this case I am looking to setup a cross between a traditional n-tier architecture and a microservices architecture which will provide eventually an API for front end systems to consume. I want to develop the site in such a way that it could be re-used for different purposes and I also want to write a site that others could reuse.
[ Front End (Razor Pages ] - [ Back End (.NET CORE) ] [ Front End (SPA) ] - [ Back End (API) ]
The above diagram shows the basic architecture. The Back End, .NET Core and API will serve two different purposes. The Razor Pages and .NET Core pages are used to provide the Admin, back office user interface and a reference implementation of the application. The SPA and API is used to provide a consumer view of the application and development of the SPA could be done by another team with the interface to our team being the API.
I am not a big believer in heavy architecture diagrams as you can see but if you needed to you could expand that diagram out and in fact if you were creating this application in a corporate environment you would need to. You probably noticed that I haven’t included a database. This is intentional as I want to keep this architecture database neutral so that you could implement the project using the database that your hosting provider, cloud platform or organisation provides. For the first iteration of this application I will use SQLite. SQLite is a small fast lightweight database which is available in mobile phones and can also be used to serve small websites. The database is held in files and can be easily copied from one system to another making it easier to set up a consistent development environment when working with multiple developers.
I am using github as the location for the source code. Creating a location for the source code is an important first step as this will let you keep a history of changes that you have made, will let other developers help you on the project and also will let you set up automation tools to perform tasks such as building and testing your code.
Once I click Create repository I have then created a new github repository. A repository is a place that you can save code into. You save code by creating a branch and then making a merge request. I will explain this process later but the concept of branching and merging is one of the major concepts you will need to grasp when working with github and git. Other source code management systems such as subversion have a different system which is more based around merging at the end of a project. Git works best by letting you create small merge requests that are incremently merged into the main codebase.
The repository itself at the moment is small only containing two files. The .gitignore provides a list of files that should never be checked into the repository. This might be binary files or files that are specific to a developers environment. The README.md file is mini WIKI that you can use to provide instructions on getting started with the project. It is a good convention in setting up a development environment to provide comprehensive instructions on getting started for new developers in the README.md file.