#Why I built this project

This project came right after my Node.js REST API assignment. The brief was straightforward: build a desktop application that can read and write data to a relational database, and do it in a way that feels close to real production structure.

Instead of putting everything in one project, I split it into three parts:

WCFEbayClient for the UI
WCFEbayHost for hosting the service
WCFEbayServer for service logic and data operations

At the center of it all was a MySQL database managed in DBeaver.

I called it "Ebay with MySQL" because the core idea was a tiny car marketplace where users can add, delete, and view cars. Nothing fancy, but it forced me to learn service boundaries and data flow properly.

#The architecture in plain language

The user works with a desktop client form. The client talks to a WCF host. The host forwards operations to the server layer. The server executes SQL against MySQL, then returns results to the client.

That sounds simple until you actually wire everything and keep ports, permissions, and startup order in sync.

The full request path looks like this:

User clicks a button in the C# client.
Client sends the request to WCF host.
Host calls service methods on the server.
Server executes SQL or a stored procedure.
Data comes back through the same chain to the client.

This project taught me that "it compiles" is not even close to "it works." In distributed desktop apps, small setup mistakes are enough to make the whole flow fail.

#Core features implemented

I focused on CRUD operations for two entities: cars and users.

For cars, the app supports:

Listing all cars directly from MySQL
Inserting a new car with an auto-incremented ID
Deleting a car by ID

The database side includes stored procedures like SaveCars and DeleteCars, and the service layer exposes matching methods like GetCars(), SaveCars(), and DeleteCars().

What I liked about this setup is that it made responsibilities clearer:

UI handles interaction and display
WCF handles communication
SQL procedures handle persistent data logic

That separation made debugging less painful because I could test each layer separately.

#Practical issues I ran into

#1. Local environment friction

Running this stack on a student laptop was not one-click. I had to run Visual Studio as admin for the server side and accept firewall prompts for the host process. If I skipped that, the client looked alive but calls silently failed.

#2. Startup order matters

If the host was not running first, the client had nowhere to send calls. This sounds obvious now, but early on I lost time debugging "code" that was actually startup sequencing.

#3. Mapping service contracts

Even with small apps, mismatched service contract definitions create hard-to-read errors. I learned to be strict about method signatures and data models between client and service.

#4. SQL and app logic boundaries

I had to decide what belongs in SQL procedures and what belongs in C#. I kept validation and flow in C#, and let SQL handle insertion/deletion mechanics. That split helped keep each layer readable.

#What this project improved for me

This was one of the projects that moved me from "single app coding" to "system thinking." I had to reason about transport, hosting, schema, and UI together.

Main skills I gained:

Designing a small but real client-server architecture in C#
Using WCF in a practical scenario, not just a tutorial
Building and calling MySQL stored procedures from service code
Understanding operational setup issues (ports, admin privileges, firewall)

This also improved how I explain architecture in interviews. Before this project, I usually described features. After it, I could describe request flow and boundaries.

#If I rebuilt it today

I would keep the same educational goal but modernize the stack:

Replace WCF with ASP.NET Core Web API or gRPC
Add input validation and consistent error responses
Introduce a repository layer for cleaner data access
Add integration tests around database operations
Package startup using Docker Compose for host + DB

I would also improve observability with structured logs so failures are visible without digging through scattered output windows.

#SEO takeaway for developers

If you are searching for examples of a C# WCF project with MySQL, this is a good beginner-to-intermediate case study. It covers the real friction points: service hosting, environment setup, SQL procedure integration, and clear separation between UI and data operations.

This project is not about complex algorithms. It is about getting a multi-layer desktop system to work reliably, which is exactly the kind of engineering problem many junior developers meet in real teams.

#Repository

You can review the full source code and project structure here:

GitHub repository