Develop Reference

ASP.NET Core Web API (RESTful) Model Naming Convention backed by SQL Views

I created an ASP.NET Core Web API project, whose template is tailored for RESTful services. In my DB instance, I have a SQL table called Organizations and a view based on that table called Organizations_v. In the .NET project, I created a model under the Models folder called Organization. The model will be backed by the SQL view.
As this an API, I don't really have any pages/views. It's not a true ASP.NET Core MVC application in that sense, right? But convention says if your model is backed by multiple tables, the model class name should end with ViewModel.
What's the proper naming convention for the model class for my use case? Since I'm using a SQL view to back the model, should I name the model class OrganizationViewModel or Organization?

The following is a pretty standard naming convention I've both used and consumed:
Using your example of Organizations:
Organization - represents your business entity: the entity you are pulling out of the db.
OrganizationModel - represents the entity you expose via your api.
It is crucial to have this separation from the very beginning. The fallout from not having this separation will haunt you, trust me. For example, if you have to change the entity (and you will) you are forced to release a new version of your api.

Model Class not showing when creating controller using Web API 2 Controller with actions using Entity Framework Database First

I am creating a WebAPI 2 application using Entity Framework 6. I have already created the model, using Entity Framework Database First Approach and I want to add a controller to my solution using Web API Controller with actions using Entity Framework. The problem I am having is that I don't know which model class to use. It is different from when using Entity Framework where I know which model class to use exactly.
My model classes.
Can someone please help/advise ?
Thanks

I think you have to build your project first after creating the entity model to be able to see the entity in the models list

Creating separate projects for entity classes ( POCO classes) and DBContext classes

I have generated my Database layer (Database First Entity Model) by using entity framework 6.1. Now all the classes generated are in the same project as well as in the same namespace i.e. Example.DataAccessLayer. For separation of concerns, I have moved my entity classes(POCO classes) that are under Model.tt file to separate project and under namespace Example.DataModel. The reason I have done this is because then I can use Example.DataModel project in my websites so that the DbContext classes are not visible and all the data management is done through my business layer i.e. Example.BusinessLayer.
Now doing this I have to give reference of my Example.DataModel project to Example.DataAccessLayer. As it is suggested in some of the tutorial, after doing this one has to change the Custom Tool Namespace of MyModel.Context.tt file to Example.DataModel so the entity classes are visible. But by doing this the DBContext and DataModel comes under same namespace that is Example.DataModel.
Now the question is, is there a way to generate my entity model with my context and entities classes in separate projects and in separate namespace without giving my DBcontext.tt file custom tool namespace ?

Why not use Code-First to connect to you existing DB? Then you have full control of where Models and DbContext lives.

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.

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.