Rest Architecture: Data Access Layer as Model, REST purpose is to call Business Logic Layer that calls DAL

Question

I'm using SOAP web service in my company and I'm used to their architecture which is Service > BLL > DAL. Currently, I'm studying REST and based from my observation, I think that Models are the same with DAL.

So what I'm planning to do is that my Controllers in REST will bypass the Models and will instead call the BLL (and do some logic) that calls the DAL. Which means my Models will be unused. Will this be okay? If not, please give some suggestions and tips.

EDIT: I'm not upgrading from SOAP to REST. I'm just studying REST and doing a separate project for this

Below is my sample REST architecture:

MyProjectDAL > UserDAL

namespace DAL
{
    public class UserDAL
    {
        public class User
        {
            public int Id { get; set; }
            public string UserName { get; set; }
            public string Password { get; set; }
            public string First_Name { get; set; }
            public string Last_Name { get; set; }
            public int User_Type { get; set; }
        }


        public User User_GetRecById(string id)
        {
            string cnStr = Utilities.Common.dbConnStr;

            MySqlConnection cn = new MySqlConnection(cnStr);
            MySqlCommand cmd = new MySqlCommand();
            DataTable dt = new DataTable();
            MySqlDataAdapter adapter = new MySqlDataAdapter();

            try
            {
                cmd.CommandType = CommandType.StoredProcedure;
                cmd.CommandText = "User_GetRecById";
                cmd.Parameters.Clear();
                cmd.Parameters.AddWithValue("@p_Id", id);

                cn.Open();
                cmd.Connection = cn;
                adapter.SelectCommand = cmd;
                adapter.Fill(dt);

                var userList = Utilities.Common.ToList<User>(dt);
                return userList.FirstOrDefault();
            }
            catch (Exception ex)
            {
                throw ex;
            }
            finally
            {
                cn.Close();
                cn.Dispose();
                cmd.Dispose();
                dt.Dispose();
                adapter.Dispose();
            }
        }
    }


}

MyProjectBLL > User

namespace BLL
{
    public class User
    {
        public UserDAL.User User_GetRecById(string username, string password)
        {
            var objDAL = new UserDAL();
            var user = objDAL.User_GetRecById(username, password);
            //add more logic here
            return user;
        }
    }
}

RestService > Controllers > UserController

namespace RestService.Controllers
{
    public class UserController : ApiController
    {
        // GET
        public UserDAL.User Get(string user, string encryptedPW)
        {
            var objBll = new BLL.User();
            return objBll.User_GetRecById(user, encryptedPW);
        }
    }
}

Answer 1

Correct the question First of all, MVC and REST are two different concepts. your question doesn't have any relation with REST concept. It is related to MVC.

---

Difference between MVC and REST: I am not listing all the difference in detail, but giving basic overview of both that can help you at this moment. You can find n number of sources on both the topic by your own.

1. Rest talks about: How to form proper enpoints? How to accept data? (in body, url path or url query param). etc....

2. MVC talks about: How to modularize your web application code?

Your can apply MVC on any web application, irrespective of what type web service architecture or guideline (SOAP/REST) this web application is using.

---

Answer to your question Now coming to MVC, M represent (business logic + data base logic both). So ideally you should not merge these two in to single once. While implementing any api you should atleast create three layer at back-end (controller, business layer, data base layer). Controller should never talk to Database layer directly there should be a proxy service for API.
----------MVC---------is----- M (Business layer+ Data Layer) + V (View) + C-----(Controller)

Ex:
Controller

@GetMapping(value = "myapi/Books")
public Books getBook(String bookId) {
   bookService.getBook(bookId); 
}

Service or Business Layer

To apply logic before any after DB calls like logging, error handling, buisness logic on the basis of if and else etc...

 public Book getBook(String bookId) {
   bookDAL.getBook(bookId); 
 }

Database Layer

public Book getBook(String bookId) {
   dbClient.getBook(bookId); 
 }

Answer 2

Regarding your code snippet, I see your BLL (which I consider your app domain) depending from the DAL. If you change the DAL structure in the future, you'll also be forced to change the BLL too (which is not the best). So, a quick win could be to decouple them a bit by adding Dto's or common interfaces. Skipping "the models" can easily become so hard to maintain in the future.

I'd also like to give you a more generic suggestion. If you really want to push your knowledge forward and you have plenty of time and resources to dedicate on refactoring, I'd like to suggest you to have a look at Clean Architecture philosophy.
My personal starting point was this video Clean Architecture with ASP.NET Core 2.1 and then you could also buy Robert C. Martin's book "Clean Architecture", or take a look at his blog HERE