I'm currently developing a minor project for school and I'm supposed to use a three layer architecture in the project.

I'm working with C# in .NET and I'm also working on Windows Forms, and with the help of Entity Framework i've made a database (Model First) connected to the project in a separate solution. After the database was successfully generated I made a database context class that both gets and sets values on the entities in my database through the classes made from the model, like so:

// User class generated by model
public partial class User
public int Id { get; set; }
public string Name { get; set; }

// Database context class that communicates with the generated class
public class DatabaseContext : DbContext
public DbSet<User> Users { get; set; }

To search through the database while doing something (for example matching a certain users name) lets say I put something like this inside one of my forms on an Eventhandler:

using (var db = new DatabaseSolution.DatabaseContext()) 
  var userlist = db.Users.ToList();
    foreach(var user in userlist) 
       if (textboxName.Text.Equals(user.Name)
          do stuff

My question is this: is it a three layer architecture the way I've written above or do I need to have an additional class that both interacts with the database context class as well as the forms?

  • Lookup model-view-controller concepts and patterns. Mar 14, 2018 at 18:18
  • I just want to make sure whether your professor is thinking along these lines: en.wikipedia.org/wiki/Multitier_architecture Mar 14, 2018 at 18:24
  • 1
    If so, what you are describing is a 2 layer architecture. If you add a WebAPI layer to talk to the database and send you JSon responses then you have 3 layers. Mar 14, 2018 at 18:25
  • Hi @πάνταῥεῖ, thank you for your response. I'm under the impression what you're mentioning is specifically for web application projects. Is the same applicable for Windows Forms? Mar 14, 2018 at 18:25
  • 1
    "Rather" means "Instead of," not "In addition to." That's why posts have a delete link. Mar 14, 2018 at 18:37

1 Answer 1


Using Entity Framework, especially model first, makes it hard to demonstrate the separation of your business logic and database layers.

Similarly your choice of Windows Forms, with its tight coupling of view to code behind page, also makes it harder to show the separation between presentation and business logic.

Its not impossible to introduce extra classes as you suggest, but its going to be a bit contrived.

I would recommend starting again.

  • First make your business layer in a Class Library project. Don't reference anything other projects or databases. This is the Business Layer

  • Second, Create another Class Library called Repository. this can reference your business logic Class Lib and SqlClient. use SqlClient with hardcoded sql statements rather than an ORM as this will make the separation very clear. Program all your load and save from the database methods in this class library. This is the Data Layer

  • Thirdly, make WPF project. Which is the new windows forms. make sure your Forms bind to ViewModel classes rather than using the code behind. This give you a clear separation between your Presentation and Business logic.

Reference your BL Class Library and use the objects from it in your ViewModel classes

Reference your Repository Class Lib and use it in the ViewModels to load and save the data in response to UI activity

You now have three Separate Projects in the same solution. Each clearly maps to a single layer of Three Layer Architecture.

The initial approach you have taken is interesting as These technologies were initial created by Microsoft to make things easy for the developer. When I click a button it calls the button_click event. When I drag my database into my project the classes, save and load methods are automatically generated for me!

It's only in larger projects where the benefits of things like Multi Layer architecture and separation of these concerns really start to show their worth.

This is why things like 'code behind' pages and EF are often considered 'bad' when used in enterprise environments.

  • "These technologies were initial created by Microsoft to make things easy for the developer." They're always trying to tease people with their RAD technologies (same as Embarcadero does with Delphi). If you're going to do some bigger real world application this leads just to clutter and pain (just 2¢ from my 30yrs experience with all that kind of shit). BTW, "code behind" isn't necessarily bad, as soon you're accessing an appropriate data mapper, instead of the infamous direct data binding. Otherwise I 100% agree with what you're stating in your answer. Mar 14, 2018 at 19:18
  • 1
    There's nothing fundamentally flawed about RAD, so long as you don't confuse RAD with making a 30 blade Swiss-Army Knife, which is what Entity Framework is. Mar 14, 2018 at 20:44
  • @RobertHarvey "so long as you don't confuse RAD with making a 30 blade Swiss-Army Knife" LOL! At our company we have a kind of a little museum vitrine, where one of the founders (he unfortunately died a few years ago), presented some his collected artifacts. Amongst old card readers, oscilloscopes and other nerd stuff, there's a simple Victorinox swiss army knife, and that Wenger Giant presented beneath each other. These are marked with post-its: "Useful, sharp and dangerous!", and the other one "Completely impractical, sharp and dangerous!" It's a bit like a Zen shrine for me, that ... Mar 14, 2018 at 21:14
  • @RobertHarvey ... motivates me how I should interact with that old software I'm faced with. ;-) Mar 14, 2018 at 21:15
  • put it in a glass case and never touch it?
    – Ewan
    Mar 15, 2018 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.