This is an ancient debate really. It goes all the way back to the first databases and the notion of "referential integrity", which in turn is a variation of the strong-typing / weak-typing debate.
Who's job is it to make sure that data is stored in a consistent and "known good" manner? MVC purists will tell you it's the controller's job. Database architects will tell you it's the model's job (or even the database's job). Ux people might even tell you it's the view's job! Big Data guys may say "It's the person using the data's job."
After being a software engineer / architect / developer for 20+ years, I've come to the conclusion that often the concern is important, but how you solve it is less important, so long as you decide on an approach and maintain it. So, my advice would be something like: rather than asking for people's opinions on dogma about it, think through solving the "who owns validation?" discussion using three different approaches: model, view, and controller. Think about how your app will behave if you solve it those three different ways. Will your end users be satisfied with all three approaches? Chances are, depending on where you put this, your end users will experience something different. Do they have an opinion? Also, which route costs you the most in terms of time and money? Which will be easier to maintain and explain to new people? What about security? All of these things are important considerations when designing a system, and dogmatic answers don't factor these things in -- they substitute a common pattern for your precise context. Sometimes that's a good idea, sometimes it's a shoe-horn disaster. Only you can figure out which applies.
I've seen it done two ways.
The first way is to do everything using CRUD methods. That's essentially the way you are describing: Create, Read, Update and Delete. Most Object-Relational Mappers (ORM's) support these four operations.
The second way to do it is to provide a Service Layer. The Service Layer exposes methods that embody business operations. In turn, it translates those business operations into the appropriate CRUD methods.
At this point, it might be useful to discuss architecture a bit.
First, note that MVC and MVP are primarily about UI. That is, they don't particularly care about what happens in the business domain. While UI can, and often does, reflect the nature of the business domain in the data that it displays and the interactions that it makes with the user, the heavy lifting is done in the Model portion of MVC or MVP.
In a web page, MVC typically looks like this:
Model <--> Controller <--> View
The Model is the "everything else" part of these patterns, the part that doesn't concern itself with UI or routing or any of those mechanics. You may have heard the phrase "thin controller, fat model." That means that business logic doesn't go into the controller. In turn, the View doesn't concern itself with data, for the most part. It's just a surface; the task of filling it with data typically falls on a ViewModel object, which is typically assembled in the Controller with data derived from the Model.
Model <--> Controller <--> ViewModel <--> View
The View displays data and accepts typed-in data from the user. It might have some interactive and validation capabilities, but even validation is not wholly performed in the client (because data from a client can't be trusted). Validation is relegated to the server, where the Controller (who acts mostly as a switchyard) typically delegates such validation to the Model.
In other words, most of the application logic that actually does anything useful is pushed as far back as it can be towards the Model.
It is for all of these reasons that MV* applications typically have some sort of Service Layer, even if it's just an internal one.
Database <--> ORM <--> Service Layer <--> Controller <--> View Model <--> View
|-------------- Model -------------|
The Service Layer relieves the Controller from having to think about Business Logic, and allows your Database Communicator (i.e. your ORM) to only have to think about CRUD.
Further Reading
P of EAA: Service Layer
Fowler on UI Architectures
Best Answer
You actually need to create a
Data Access Layer:1- Create a New Class Library
[ProjectName].DataAccess2- Create a Class Named
UserManager.3- Create a Method called
AddUserthat takes the User Model as an argument. and inside that method, you write the logic to insert the user to the database.Depending on the Scale of your system, you might want to Create a
Bussiness Layer(Class Library) that you use in your controller in order to Call one of the data Access Layers (SQL or Oracle or etc). If you reach that complexity, you might need to create interfaces with (AddUser, GetUser, DeleteUser) and provide both SQL and Oracle Class Implementation of that interface and choose one from your configuration.If you need more details, please let me know.
Edit After your Comment:
You may have a
GetUsers()andGetUserByID(int id)or byNameWhatever. That all depends on what you need in your UI and what functionalities you're giving to the user.However, you should not Query all data from database and then filter what the user requested via code, you should only query the data you need from database. Unless you're showing the complete list in UI and then providing Search functionality on the screen.
Whether to pull a complete table from the database is something to think about before doing. In real applications, you have to consider the size of the table, if you have a huge one you may need to do some pre-filtering (where the end-user selects a department for example and then you Call
GetUsersByDepartment(int depId)). Anyway, you can have a option to query all the users if the end-user requests that through your app screen, but he might need to wait for the data to be pulled. All these methods should be in youData Access Layerfor now considering your case of not having aBusiness Layer.