Develop Reference

How to do Model validation in MVC with Web API 2?

I am new to Web API2. My solution has 3 projects (MVC, WebAPI2, Class library for EF). I have below doubts.
1) Have kept WebAPI and MVC as separate projects for separation of concerns. Is it advisable or it is better to keep both in single project?
2) With WCF we can take service reference in MVC to avail all DB class models so that it will be easy in MVC to scaffold the controllers and to add Model validations. How to do that with Web API2 as I will not have reference in MVC for DB classes. Do I need to create duplicate DB class models in the MVC project for scaffolding purpose and model validation purpose?

Your title confuses me a fair bit, but model validation can be done with validation attributes. I will try and answer the questions in the body of your question post.
It depends on how you expect to use your MVC and WebApi projects.
Keep in mind you may make things easier for yourself if they in the same project so you don't need to worry too much about RPC. But who knows how you intend to use them.
WebAPI is normally used for integration with systems other than your own. For this reason (de)serialization and request/response handling is highly customizable. The models used for the WebAPI controller are often specified or provided to the system the interface is intended to integrate with.
The model used for the WebAPI or MVC controller should be separate to the entity model for your ORM. The reason you would want to do this is that the data in your entity model does not always fit the use of the view or the validation of the view model that is sent back to the controller from the view.
In both cases the models that interface your WebAPI and MVC controllers should be designed to accommodate your use cases and should be fairly decoupled from your entity models for persistence.
So to answer your second question you probably only need one set of entity models and probably only one dbcontext implementation, but have all of that in its own project so that if you do have separate MVC and WebAPI projects they both depend on that EF project.

ASP.NET MVC Models in Seperate Project, not able to select to use Model Classes

First serious attempt at getting into MVC. Understand the principles (so I think).
I've created a fairly simple application using Fluent NHibernate for my Data Access and have abstracted it with Service Layer above that. My entities are in my Domain and I have a few other projects as below.
MyApp (error reporting & constants)
MyApp.DataAccess (FNH)
MyApp.Domain (entities)
MyApp.Interfaces
MyApp.ServiceLayer
MyApp.Utils
MyApp.Web
I have just added these projects to a new MVC solution, and when attempting to create a View based on a simple Controller, I don't get any options for which Model class to use.
I figure this may be something to do with the namespace of the classes I wish to use for my Models (MyApp.Domain), but not sure how to go about pulling them in? I have a reference to the DLL in my MVC project and everything compiles fine.

MVC architeture with EF Code First

I'm trying to understand how to separate the model class / MVC to interact with the database design in EF CodeFirst.
For example, considerate this simple architecture:
MyApp:
1. WEB
2. DATABASE
3. ModelEntity
The questions is:
Who should call the database without show tables in WEB UI?
The ModelEntity or model/MVC?
Is it necessary to use mapper in this case?

Your controller will be your middle man between the web ui and models, which represent tables in your database.
Normally, you web UI will use ViewModles, which may not be consistent with your ModelEntity, and that's when a tool like AutoMapper is very helpful.

This is how I usually have mine separated out:
1) Data layer: entity models, EF mappers, EF contexts
2) Domain layer: domain models, entity to domain model mappers, query objects, query handlers, command objects, command handlers, services
3) Application layer: view models, domain to view model mappers, application facades
4) UI layer: controllers, razor views, maybe some other view models that didn't fit into the application layer

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/

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.