Following on from Part 4, where I provided the links to the CarShop views SQL, I have now published the C# project which defines the data model classes for the CarShop database tables and views. The data classes project has been separated into it’s own project as this will be shared as a dependency with the CarShop Blazor Server project and in future, I will develop the API’s in a separate project.
The project has been published on my GitHub repo here.
You can also follow the guidance from Microsoft to create model classes with the Entity Framework, documented here.
Following on from Part 3, where I provided the links to the CarShop database seeding SQL, I have now published the database view SQL scripts in my public GitHub repo. At present there are two database views.
It is likely that over the course of developing the project, the number of views will expand, hence the reason to separate out the location of the view SQL scripts as apposed to the database mode creation or data seeding SQL scripts.
Following on from Part 2, where I provided the link to the CarShop schema deployment SQL, I have now published the database seeding scripts in my public GitHub repo, for the initial supporting data. At present there are six tables in the database which have data seeding scripts.
Following on from Part 1, where I introduced the CarShop project, I have now published the database scripts in my public GitHub repo, for the data model. At present there are nine tables in the database schema, which need to be created in a specific order to maintain relationships. The tables are listed below.
CarManufacturers – Table to hold all car manufacturer details
CarModels – Table to hold all car models
VehicleStatus – Table to hold the vehicle status e.g. “For Sale”
CarFuelTypes – Table to hold the fuel type for a vehicle
CarColours – Table to hold the car colours
Engine Size – Table to hold all car engine sizes
Vehicles – Table to hold all car vehicle details which has relationships to the above tables as per the Part 1 CarShop project blog post showing the schema diagram.
Salutations – Table to hold all customer salutations
Customers – Table to hold all customer details which has a relationship with Salutations
Some of the tables hold default e.g. Vehicles previous owners has a default of 1 since the vehicles are not new at the Carshop.
Over the past few months I have been working on a sample project, which will eventually be published to my GitHub repo. The project specifically focusses on Microsoft Entity Framework with an Azure SQL database and also utilises Blazor as the underlying UI and logic layer, including DevExpress for Blazor UI components. This is an initial post which describes the project and it’s capabilities.
The CarShop project was envisioned from wanting to build something new and then work on multiple articles rather than only a few for a project, for part of this year. This will enable me to provide updates at various intervals and at some stage, including the publishing of the code.
Why a CarShop?
Since I am car fan and have been for many years, I thought this would be an exciting project to work on this year. With Blazor + .NET and DevExpress being some of my favorite development frameworks, I thought this would be ideal as a project.
The database schema
Since I am using the Microsoft Entity Framework in the Blazor Visual Studio project, the schema was exactly where I wanted to start. As the iterations developed, I decided to go straight into Azure SQL to provision my tables, entities and relationships, primary keys and foreign keys etc. The project needs to store car details (at a basic level), customer details, car manufacturers, car models, fuel types, engine sizes etc. Whilst it is a simple model to start with, it’s relatively simple to expand the schema as I see fit, both from the SQL backend as well as the coded elements and data classes.
Since this is a relatively simple sample project, the data is held in a single Azure SQL database. As you can see, the Vehicles table has the most relationships with car fuel types, vehicle status, engine size, colours, models and manufacturers. For the customers table, I’ve kept the design simple for now although I intend to expand this into a scenario where there may need to be some data quality checks and periodic checks around when the customer data was last updated, for reasons I will include in a future post.
Part 2 will focus on the Transact-SQL, so that the schema can be provisioned.
Recently I was was asked how architecture saves money and reduces risk in an organisation. I had 15 minutes to present a simple answer and demonstrate an example of how high-level analysis improves overall costs and reduces the risks as well as explain the challenges.
I created a presentation to describe this topic, with the agenda below.
I’ve recently been developing a application for the car industry, to record vehicles, models, customer information, vehicle sales and storage of images etc. This is ASP.NET Blazor application which utilises Entity Framework Core, Microsoft Azure, Azure Web sites and Azure storage. One of the features I thought would really be interesting is for the car sales administrators to enter new vehicles into their stock and then dynamically have a component which allows them to query the vehicle information via the DVLA VES Web API.
Sometimes, to start with developing a component, I develop the component code outside of Blazor i.e. a Console application which can contains all the response structure, associated methods and calls the VES API with a HTTP client.
Now that I am finished with the basics of calling the VES web API, I can now expand this with all the necessary error handling e.g. HTTP error codes, and include this as a component within the Blazor application.
I’ve published the ASP.NET console application in my GitHub repo in the link below. You will need to request a VES API key and utilise your registrations, or set these as arguments in the console app, or just set a static string for this as it is in the current code.
I’ve recently had a requirement to backup managed disks to Azure blob storage. Rather performing this manually, I scripted this with PowerShell. I created a structure within a .CSV file as an input file, which specifies the Virtual machine names and the storage container and folder, where the disks will be copied into. The script and a sample input file is in my repository below.
The project site is accessible on Microsoft Azure below and I have now uploaded the code to my GitHub public repo. Follow the links below.
For a while now, I have been adding code inline within my blob posts. I’ve now released a public repository on GitHub, which I will be using moving forward to publish all my community shared code, free for use with the MIT license.
I will start to publish my previous code into the public repository, for now I’ve published a recent .NET 5 console app which is a basic RSS reader that currently reads the .NET teams RSS feed. My public repository can be found below.