C# – Entity Framework designer not effective anymore

At a minimum, business logic validation should go within the Controller for the framework you're using. If the validation logic is portable, creating a separate validation module, called by the Controller, would also be okay.

In general, place the validation logic as close as possible to the layer it affects. Likewise, validate items at the most appropriate layer (appropriate defined by what's being affected). The concept is a related to encapsulation and the SOLID principles. The goal is to allow changing out the individual components as needed, as well as making the validation logic more portable.

To be a little more clear, if there's validation logic to protect the database from errant changes, then that logic should be placed within (or called from) the Model. Likewise, input validation belongs within the View.

Some validation logic can pull double (or triple) duty or would be common across multiple modules in the same layer. It's appropriate to create a separate module for that logic. At the risk / expense of duplicate checks, I would still have each layer validate for the aspects it is responsible for.

Assuming you are using a single database for both, I would look at having the database and ORM layer behind a web service that both UIs can consume. That would allow you to put your business logic where it needs to be and decouple things so that the day you need a mobile interface or whatever else, you don't have to write another data access layer. Assuming you are using WCF on a windows stack, some of the native bindings should be as fast as you need them to be and designing for this environment forces some good habits in terms of data management.

Having the facility to put some logic on the service side also saves on having to write anything twice.

The downside is that updating your API affects all your clients, so you might want to have that well defined to start with and it does mean your desktop client and your web api client are tied in more closely to the application as a whole, but given that they are sharing a data store to start with, that is not necessarily a bad thing.