Assistance with C# Logic

A big but necessary leap I'd say. I'd suggest creating a new solution with the files I laid out - but don't copy/paste. Type as much of it in as you can - that way you learn what's going on, and you can possibly try to understand it better in smaller chunks.

Also, since you're a beginner, not sure if you knew what I meant about "business logic" & "service layer" and "UI layer".
 
Business Logic and Service layer I'm not 100% on, though UI = User Interface, so obviously that's dealing with things like WinForms or anything related to the stuff the user interacts with.

If I had to guess, Business Logic would be the core logic of the program, and the service layer is the bridge between the UI and the business logic?
 
Business Logic and Service layer I'm not 100% on, though UI = User Interface, so obviously that's dealing with things like WinForms or anything related to the stuff the user interacts with.

If I had to guess, Business Logic would be the core logic of the program, and the service layer is the bridge between the UI and the business logic?

Service layer and business logic are actually the same thing - just different terms. The business layer / service layer is the layer in between the UI layer and if you have a back end database. That way your DB/storage (or Repository layer) only interacts with the Service/Business layer, and the UI layer only interacts with the Service/Business layer. That way changes are less catastrophic, and you can redo the UI quite easily.

And when I say "layers" I mean separate projects in a VS Solution. So you have 3 separate projects that interact with each other in a layered approach (the term for it is called "lasagna" code - a spin on messy "spaghetti code").
 
Service layer and business logic are actually the same thing - just different terms. The business layer / service layer is the layer in between the UI layer and if you have a back end database. That way your DB/storage (or Repository layer) only interacts with the Service/Business layer, and the UI layer only interacts with the Service/Business layer. That way changes are less catastrophic, and you can redo the UI quite easily.

And when I say "layers" I mean separate projects in a VS Solution. So you have 3 separate projects that interact with each other in a layered approach (the term for it is called "lasagna" code - a spin on messy "spaghetti code").

This sounds... difficult to picture. Most of my programming is visualised before I write it, so I know how I want it to "flow". Doing something like this with multiple projects would really screw with that system.
 
It's pretty easy.

Example, here's an architecture diagram from Visual Studio of a project at work that I'm involved with, where we did the layered approach:

pTPkX1Y.png


The ".MVC" is our UI layer, the ".Public" is our Service layer, and the ".Dal" is our Data Access Layer, or Repository.

We do have a line going from our UI directly to our Repository layer...which we shouldn't do, but we had to for one reason or another. But most of the logic from the UI layer interacts with the Service layer to get data from the Repository/Dal layer.
 
Back
Top Bottom