Develop Reference

UI -> WebAPI Controller -> Services Pattern

I've been learning about writing WebApi design patterns.
I am trying to create a simple CRUD web app with ReactJS UI and C# .NET CORE webapi with sql backend.
Articles show that specific Repositories are a direct reflection of the tables inside the DAL. And the services layer handles the domain objects and draws entities from the repositories layer. Those same articles also show the controller being designed for changing entities from just one data table in the DAL. So basically, an Employees table inside the DAL would have an Employees Service and an Employees Controller. Is this the correct interpretation?
In my example:
I am confused about which path is the proper way to do it.
I have a form that needs to get, post, put records from two different tables (Employees and Devices) in the DAL.
So do I build a single controller that can handle this form's requests (with JSON obj) or do I build two controllers and code the UI to speak to two separate controllers (one for each table)?
In this example, I skipped the repository layer because there's not much logic to need both a repository and service layer.
Please see the two alternative diagrams:
Multiple Controllers
Single Controller

converting MVC EF to 3-Tiers Architecture model

I was working on my project using MVC3 & Entity framework and the model of my project was about my entity.emdx only.
now i want to convert this project to 3-tiers architecture that will be about:
(presentation layer :my old MVC project's views and controllers),
(business layer:all operations related to data base),
(data access layer: my entity framework(.emdx)),
This is what i concluded,,
and if i am correct then the model in the MVC project (presentation layer) will be empty ,,,is it possible in MVC that doesn't contain Models?,
if my thinking is wrong so, what is the correct thing to do?

Yeah its possible to don't have model, the data access layer you created is now act as the Model found in presentation layer(when it was 1 tier)..
The Models now are the entities in the data access, but you Make can your Model even in 3 tier application for some reason like if you want to create ViewModel, see this example about it:
http://www.edandersen.com/2013/05/30/asp-net-mvc-basics-part-2-viewmodel-to-model-mapping-and-editing/

Where to put Business Logic classes in an Entity Framework - ASP.NET MVC 4 Solution?

I have a Solution with one project is Entity Framework and have my ASP MVC project, I looking for some advice or opinion about the idea of create in top of my POCO objects and the DBContext, a Business Logic Layer with static classes that have the all the methods (example a ContactBLL class with GetContactByID, GetAllContacts, GetContactsByType) to allow the access to the model data and that can be accessed in the Controllers Actions. In that way I don't have to put the implementation code of this methods in Controller Actions methods, and it can be reusable invoking this methods in other Action Controllers. I will appreciate your opinion because it could guide me to respond a question I've asking to myself around a week based in the answer to this one (about where to define the DBContext and how use it).

You can create different projects according to core functionality.
Data Access Layer(DB context and repository etc.) you can make Project.DataAccess, it will have only db context class and repository.
Business Logic Layer(Project.Business) it will have business logic and make call to data access layer.
UI Layer(Project.WebUi) it is mvc project.
and so on.
for detail info you can see this http://prodinner.codeplex.com/ code

Create separate class library for your POCO,
then create another class library for your repository, this should
include only the interfaces needed for your repository
and the implementation will be on another class lib like Project.EF,
Project.NH which will include Entity Mapping, Migration, Repository
implementations. but in reality, chances are you wont be changing
your ORM lib once it was implemented because it will just cause you
a lot of headache(just my 2cents).
you'll create your business layer(class lib) and
web project as separate lib. Models folder of your MVC project will contain your ViewModels.
this is what Im using right now and of course not the best structure, it just something that Im happy with :). hope it helps.

In general, there are four standard projects in a ASP.NET MVC - Entity Framework solution. They are 1) MVC, 2) Core/Business Logic Layer(BLL), 3) Data Access Layer/DBContext (DAL) and 4) Common/Utility.
Standard MVC project consists three main elements which are Model, View and Controller. However, middle to complex solution usually cuts off the Model element from MVC project and moves it back to BLL, we call it as ViewModel(POCO). Following this structure, MVC project is now responsible for employ/use the services from BLL and control the UI through controller.
Business Logic Layer (BLL) is the core of implementing business logic. It is responsible for serving request from the MVC project and work with DAL to persist data. As said above, BLL is the place to define ViewModel, its relations as well interface/ abstract class to support implementing design pattern. Viewmodel(POCO) is likely mapping one-one to data entity at DAL but we do not use the data entity directly on View. Following this structure will help to increase the customization on ViewModel like adding constrains
DAL is the place for DBContext and its data entities.
Common project consist of shared functions like Logging which is used in 1) 2) and 3)
Please read more at
https://www.codeproject.com/Articles/70061/Architecture-Guide-ASP-NET-MVC-Framework-N-tier-En
https://chsakell.com/2015/02/15/asp-net-mvc-solution-architecture-best-practices/

Asp.net Where to build viewmodels

I'm building a mvc application from scratch. Currently i'm very in doubt where to put the mapping from domain entities to view models. I have the following project layout
MVC application
Bl Layer (per domain, so 1 for orders, 1 for customers etc)
Repository layer. Per table mostly.
For example, now I need to build a grid. The controller is called to get the grid on the screen for example on the Index page. Then the index page calls the BL layer that eventually calls the repositories to access the data from the database. Now my question is, where should I map the domain enities to the viewmodels? I could do this in the controller or in the BL layer. What are the pro's and con's?

You should keep mapper logic at BL in seperate class not at controllers. Thats mainly because Its not the responsibilty of your controller to do the mapping. There should be another class to handle this mapping responsibilty. That's what SRP principle says, I think.
Better you have a look on some Object Oriented design SOLID OOD Principles.

What about the Model in Large ASP.NET MVC Project

I've been doing some research on using ASP.NET MVC and Entity Framework together for a fairly large project.
Most examples separate the .edmx file from the MVC project by moving it to a new DAL project. In this project you would also find repositories and interfaces.
While this approach makes perfect sense to me, there's one thing I can't seem to figure out: what about the Models in MVC? In most examples the Controllers address the repository interfaces from the DAL project directly, so the MVC Models are no longer used? Or is it a good idea to keep using them, but map them in the Controller?

There are 2 types of models:
domain models
view models
The domain models represent your domain entities. They could be the autogenerated EF classes from your database or coming from somewhere else such as proxies generated from a WCF service that you are consuming. Those should live in your domain layer.
View models on the other hand go in the Models folder in the ASP.NET MVC project. Those are specific classes that you define for each view. The controller actions will query your DAL layer to fetch one or more domain models and instantiate a view model which you have specifically defined for the given view that you want to render from this controller. So a view model could hold information from multiple domain models (just because in the given view you need all this information). Then the controller passes the view model to the view for displaying.