I am assuming it is a line of business app. I would probably have a server-side API for the business logic and integrations (like SQL), if possible. This helps to logically separate UI concerns from business and integration concerns. When it is all within the app, it becomes easier to mix concerns. Having your own API also establishes a path for providing data to other apps. Otherwise, it creates a huge dev limitation when you let other systems directly connect to your SQL database. Because then it is difficult to make database changes without breaking others. It is better to expose an API for them. Then you provide exactly what they need through the API and can still make database changes internally without breaking them.
It seems pretty natural given the other Microsoft-based constraints to choose the .NET platform. Visual Studio is a great IDE for this platform. Language and framework is probably where I will differ from common recommendations. Assuming it must be a desktop app, I would probably use F# and WPF + Elmish for the UI. This mostly constrains WPF to just be for display elements, and using Elmish (MVU pattern) to handle UI behavior. I do not care for WPF's behavioral abstractions like MVVM (nor just about any UI framework's), so I had rather use MVU here.
WPF because of backward compatibility. UWP is the latest tech, but it only works in Windows 10. If the app is only used inside of a specific business, and you have guarantees that all PCs run Windows 10 there, then UWP might be more viable. If you want to go for compatibility for even ancient/unsupported windows versions, then you might want to look at WinForms. Altho WPF can run on Windows versions all the way down to Windows XP.
.NET Core 3 is supposed to add support for Desktop apps in 2019. But today, you would likely have to target .NET Framework for the app project itself. You could still target .NET Standard for libraries, and those would work on .NET Core apps in the future.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I am assuming it is a line of business app. I would probably have a server-side API for the business logic and integrations (like SQL), if possible. This helps to logically separate UI concerns from business and integration concerns. When it is all within the app, it becomes easier to mix concerns. Having your own API also establishes a path for providing data to other apps. Otherwise, it creates a huge dev limitation when you let other systems directly connect to your SQL database. Because then it is difficult to make database changes without breaking others. It is better to expose an API for them. Then you provide exactly what they need through the API and can still make database changes internally without breaking them.
It seems pretty natural given the other Microsoft-based constraints to choose the .NET platform. Visual Studio is a great IDE for this platform. Language and framework is probably where I will differ from common recommendations. Assuming it must be a desktop app, I would probably use F# and WPF + Elmish for the UI. This mostly constrains WPF to just be for display elements, and using Elmish (MVU pattern) to handle UI behavior. I do not care for WPF's behavioral abstractions like MVVM (nor just about any UI framework's), so I had rather use MVU here.
WPF because of backward compatibility. UWP is the latest tech, but it only works in Windows 10. If the app is only used inside of a specific business, and you have guarantees that all PCs run Windows 10 there, then UWP might be more viable. If you want to go for compatibility for even ancient/unsupported windows versions, then you might want to look at WinForms. Altho WPF can run on Windows versions all the way down to Windows XP.
.NET Core 3 is supposed to add support for Desktop apps in 2019. But today, you would likely have to target .NET Framework for the app project itself. You could still target .NET Standard for libraries, and those would work on .NET Core apps in the future.