We Keep Coding

Where should the controllers be in a multi layered solution

Description:
I have a solution in Visual Studio which has multiple projects as application layers.
Business Logic (.NET Standard)
Data Access Layer for database operations (.NET Standard)
Web Application (.NET Core)
Xamarin Forms Mobile
Xamarin Android
Xamarin IOS
Xamarin UWP
Question:
In which layer should i create my MVC controllers as a good design practice for this scenario?

Controllers belong in the web layer as they handle web related activities such as routing, handling incoming http requests, etc.
Ask yourself what a controller is meant to do and then see which layer those activities make sense in... does handling incoming http requests make the most sense in a data layer? no, the data layer should be related to data I/O.
Does handling incoming http requests make the most sense in a business logic layer? no, the business logic should contain logic only needed to do the business/domain logic of what you're building.
Does handling incoming http requests make the most sense in a web layer? Well yes, http requests are part of the web as we know it.
There is an awful lot of information about n tier (aka onion) architecture on the web. Here is one example I quickly dug up that goes into more detail than my answer above

A web application and Xamarin.Android app communicating to a Service/API

I'm working on an .Net application in which a user can either use a Xamarin Android app or a web application to use the system. I would like to put all the business logic at one place and both the applications shall use it.
Considering that I have "NO" experience in Web APIs or Services, how shall I design my application?
However, I'm ready to learn both (Web APIs or Services) if required for the implementation.

Considering that I have "NO" experience in Web APIs or Services, how
shall I design my application?
The question should rather be, do you need to call some external services, or can you do everything locally on the phones? If some external services are required, you need web API call from your different platforms. The business logic goes in your API.
If everything can be done locally, you can just share your client side code.
As you probably know, Xamarin app's usually follow a MVVM architecture.
It does not mean the business logic must be in the sharing ViewModels (I actually wrote a blog post about that if it you want more information).
The business logic must be in the domain models, and possibly some services.
Thus, in the end you can share the c# code of your domain models and business services between your xamarin app and your web application.
Hope it helps.

OWIN FLOW (from MVC 5) to Class Library

I've a website with 3 layers.....
MVC 5 (Presentation layer) with custom OWIN to store cookie. It checks with Service layer to validate user and then create a cookie.
Service layer (Class Library): Presentation layer has reference to this layer and any communication with database, needs to go through these.
Data layer (Class Library): Data layer with SQL statements. This layer is responsible for any communication with database. Service layer has reference to this.
All the above mentioned layers reside on same machine but within seperate projects. There is also potential that I've had to move all the layers to its own seperate servers (Presentation, Service, Data).
Now, once the user is authenticated and authorized, I want to basically pass the identity to Service and Data layers as I don't want anyone to call the service and data layers directly. But I don't know how to do it.
Could anyone please show me the light?

Cookie/Token is only usable in browser-based environment (that means it only help to secure your presentation layer.
If you want to secure the Presentation layer (which is class library as you mentioned), quick and dirty way is store a private key inside Web project, and every time you call a service, validate the private key passing in.
Standard way is use StrongNameIdentityPermission to prevent others to reference your DLL. (https://msdn.microsoft.com/en-us/library/system.security.permissions.strongnameidentitypermission.aspx)
Extra note: consider to use obfuscator tool to prevent others to decompile your DLL code.

Replace (Entity Framework Connection) to (WebServices) on Services Project

We have the following structure on our project in order to get data.
Acces to Database Using Entity Framework
ProjectName.DAL
Services that call Entity Framework.(UoW)
ProjectName.Service
Our Actions inside Controllers call Services and return data needed.
ProjectName.Web
The Question:
Our services take info directly with Entity Framework, What are the advantages and disadvantages about creating WebServices in order to replace the connection with EF? "In that case only WebServices will have access to Entity Framework,"
ProjectName.DAL
ProjectName.WebServices
ProjectName.Service
ProjectName.Web

The main advantage is that you would have a more decoupled design.
By exposing your DAL through web services you "disconnect" it from your frontend. For example, a mobile app, a web app and a WPF desktop app could all access your DAL through the same web services. So you can reuse your DAL accross different apps which can save you a lot of development time. Have a look at ServiceStack and advantages of its web services.
Disadvantages? Having to do some additional development work and testing. If your app is a simple and will not be used in different environments it may be overkill to use web services.

Disadvantages:
Web services tend to consume more resources from your server than just a plain CLR (aka dll) layer in your project.
whatever web service you plan to use (legacy web services, service stack, wcf, Web API, etc) you'll find that all of them have to use a process to serialize the data and it could be the case that you'll need to do the inverse process in your front end application.
you have to design your ws very carefully because you have to think how you're going to expose those services and the level of encapsulation/abstraction you will have to put in place, a bad design in a web service layer definetely will be a headache for you during development and production.
Security: In most cases you will have to validate every input in those web services as well
Advantages
well that's very relative to call an advantage, it depends more on what are your app requirements, some questions you need to answer are like the following:
Do I need to share data with other apps (mobile, desktop, other web
apps)?
Do I need to expose some functionalities to other business (third
parties)?
Recomendation
If you plan to do a CRUD application I'll recomend to go with REST definetely is the best option due to it's architecture (POST,DELETE,GET,ETC).
if you don't need you a web service right now, you can try to develop your service layer kind of like a service implementation in service stack but try to remain as POCO as possible and if for some reason you'll need a web service you can try to refector the service layer intead to have another level of indirection in the middle.
just my two cents...

WCF Data Service - Proxy mid-tier service

The project we are working on is a classic 3 tiered architecture. tier 1 being the database server, tier 2 the application services and tier 3 the presentation tier (a web site).
In the application services tier I have a project that includes an entity framework model and a WCF data services based service that exposes the entities within the model e.g.:
public class DataService : DataService< PortalEntities >
This is a fully fledged OData service that can be queried through the URI e.g.: /dataservice.svc/mytable?$filter=contains(fieldname,’string’). This is great for the guys developing anything using jQuery as all they have to do is define the query. The problem is that this service is a mid-tier so it cannot be seen by the outside world.
The solution that I am trying is to expose another WCF data service on the web site that exposes the entities created by the service reference. If I add a service reference to the mid-tier service it gives me a data context that data context is being used in the new WCF Data service:
public class DataService : DataService< PortalEntities >
I do have to overwrite the CreateDataSource:
protected override PortalEntities CreateDataSource()
{
return new PortalEntities(GetMianModelServiceUri());
}
The new service does act like a proxy and does return the entities exposed (the query .../Services/OData/DataService.svc/tbl_Country works fine).
But when a query is passed to the service e.g.: .../OData/DataService.svc/tbl_Country?$select=Name it throws a not implemented exception.
Any ideas on how to extend the web site service so that it supports the same queries as the mid-tier service?

If you don't need to change the shape or functionality of the data server, you should be able to simply forward the requests and responses, just like a transparent HTTP proxy. The only difference you might need to do is to tweak the service URL. Since the proxy service will have a different base URI than the real service, the payload would contain the real service URIs (in the links and such), which would not work. You can workaround this by using a custom host for your real service and lie to it about its URI. This is done through IDataServiceHost2 interface, you return the "new" URI from the AbsoluteRquestUri and AbsoluteServiceUri properties. Nice sample of an implementation of the interface (although for a different purpose) is here: Link.
If you need to change the shape or functionality, then you really need a true layering.
Layering one WCF Data Service over another is currently rather hard. The LINQ expression trees generated by the "Server" are not always understood by the "Client" LINQ provider. That's what you're running into.
There's a prototype (more like an experiment) of making this work to some extent by rewriting the expression trees. It's part of the OData Provider Toolkit which you can download here http://www.odata.org/developers/odata-sdk#/media/7579/odataprovidertoolkit.zip. (It's in the Experimental folder, AstoriaOverAstoria project).
But please be aware that this is really just an experiment to show what kind of issues are there to be solved and so on. I definitely recommend to NOT use it in any kind of production environment.

I have found it possible to expose a service on the Web Tier that references a service (not data directly) on the App Tier. This only works for queries at the moment. I am not sure what is needed to get it working for updates, deletes etc. Any Ideas anyone? Anyway, here are some instructions and code snippets:
First you create a WCF Data Service on the App Tier bound to your edmx model.
Then create WCF Data Service on the Web Tier not bound to an edmx model (custom).
Create a Service Reference in the Web Tier Service to the App tier service.
Pass the Entities type to the DataService generic declaration (should be angle brackets for VB but I couldn't get them to show:
Public MyWebTierService
Inherits DataService[MyServiceReference.MyAppTierEntities]
Add an override for CreateDataSource() that creates your reference to the App Tier:
Protected Overrides Function CreateDataSource() As MyServiceReference.MyAppTierEntities
Dim ctx = New MyServiceReference.MyAppTierEntities(New Uri("http://yourappservicelocation/AppService.svc/"))
Return ctx
End Function
All you do now is create a reference to the service or bind it to your client app that
supports OData. JSONP support can be added if required.
So, this works fine for Queries but not for updates, probably because the Types are not the same (they may look the same, but are in difference assemblies after all). So, tracking is lost between the Web and App Tiers.
It may be that we have to implement IUpdatable on the Web Tier to solve this. Not sure yet so any input would be useful.
Hope this helps