Okay, we've made it to the end of section two, and we'll just wrap up with a fairly quick summary
and just recap on what we've done so far in this training course.
We've taken a look at Net and what it is, and bear in mind we're only really scratching the surface
of the.
Net framework because it's big.
It's an all encompassing develop anything kind of framework, and we're just focusing on the rest API
side of things for what we're using it for.
We created our project with the.
Net CLI.
We then looked at our project.
We took a look at Entity Framework and using SQLite for our database functionality.
And then we saved our hard work into git.
And what did we achieve?
Well, we're able to query our database for data and return it via our API controller.
So we can now receive HTTP requests, and we can return HTTP responses that contains the data that we
can retrieve from our database.
So it doesn't feel like we've done or accomplished too much, but we have to start somewhere.
So just some frequently asked questions.
And often in the Q&A, I see questions such as Lee's.
So I'm going to try and cover them all in one go here because I do see them quite frequently.
Why did I use SQLite?
I did try and explain this.
It's just a convenient database that we can use that doesn't require us to install a database server
onto our operating systems.
Our database is just stored in a file, and it's just a very quick and easy way to get up and running
with a database.
And it's great for development.
It's not great for development in all circumstances.
You might be reliant on specific functionality that SQL server or PostgreSQL gives you.
In that case, you would just use SQL Server or Postgres for development as well.
I know in our circumstance, in this case, SQLite is going to work fine for us.
So that's the reason for that.
But we will not be using it in production I promise.
Sometimes I get asked why did I use the.net cli?
Why didn't I create the projects using Visual Studio?
Well, I can't use Visual Studio when I'm on a mac, for starters, because that's a windows specific
application, and I'm talking about the full version of Visual Studio here.
Visual studio 2022.
That comes with a graphical user interface where you can right click Create New Project, and you can
pick a web API type of project.
And Visual Studio can set things up for you, but a dotnet CLI, I'd still recommend using it because
it does give us a very quick, fast way of creating projects using templates that Microsoft provide,
and it's consistent across Mac, Windows and Linux.
So that's the reason for that.
Why did I use VS code?
Well, it's a popularity contest and it is the most popular code editor or IDE.
Around 70% plus of developers use VS code every day for development tasks.
And it's the same experience on windows, Linux, and Mac, and it's free to use and it's an obvious
choice to demonstrate on a training course.
I would highly recommend, though, giving the JetBrains products a go because they're now free to use
and they are excellent.
So if you did find small frustrations with VS code, then please do give those a go.
You can write the code in those on this training course.
No problem at all.
And why would I use F?
Why didn't I use another object relational mapper?
Well, I'm purely sticking with the same technology stack here.
Really.
Microsoft make.
Net and Microsoft make Entity framework.
That's the reason and no other reason than that other object relational mappers could be used, of course,
but I'm going for Entity Framework and there's no incorrect choice here.
It's really just a preference in this case for this particular application.
And why did I write the code this way rather than that way.
And this can apply to any code that we write on this entire training course.
And there is a saying that comes along in development.
If it works, it's correct, which is kind of tongue in cheek.
It's kind of right.
But all of our code needs to adhere to certain principles.
It needs to be maintainable.
Is the code easy to read, understand and modify.
That's what we're going for with code.
And when you're thinking about why did I do it this way, then these are the principles in mind when
writing the code in a certain way.
Scalability comes into it.
Does the code perform well as the system grows?
Robustness as well.
Can the code handle edge cases and unexpected inputs gracefully?
Test coverage.
Are there tests ensuring that future changes don't break existing functionality?
Well there isn't.
I'm not covering testing on this course, but when you are writing code, especially when you do come
to the stage where you are writing tests, you'll find yourself writing code that makes it easy to test
or use a different approach to writing the code with test driven development.
Again, not something I'm covering on this course, but that, of course, encourages you to write code
that's easy to test, as you're not going to write a convoluted test to start with.
To write easier code, you'll write easy tests and then write code that suits those tests and of course,
adherence to best practices.
Does the code follow industry standard patterns and principles?
So these are the goals that you're aiming for as you're writing the code.
But there's always more than one way to achieve the same result even with applying to these principles.
Another phrase that I quite like that does resonate with me make it work.
Make it right, make it fast, which was coined by Martin Fowler.
And this just emphasizes an iterative approach.
First of all, we prioritize functionality, get the code to do what we want it to do.
Once we know it does what we want it to do, then we can refactor for correctness and maintainability
again, making sure that we don't break any functionality.
And then finally, once you've done those two parts, finally optimize it for performance.
And this is a good approach for beginners as well.
Making it work is is the crucial factor.
And then once you've got it working, if you've got a spaghetti code of mess, then obviously you can
refactor it.
Make sure what you're trying to do still works.
So coming up next, we're going to take a look at the client side of our application.