DEV Community

Daniel Coturel
Daniel Coturel

Posted on

What would you do?

Hi everyone,

I open this post to gather some opinions and insights. The question is: ¿wich language, framework and IDE would you choose if you have to start now (October 2018) to develop desktop software running in Windows and connected to SQL Server?

Saludos,

Top comments (9)

Collapse
 
phlash profile image
Phil Ashby

Individuals and interactions over process and tools:

  • How much time do you have to learn new things?
  • Are you comfortable making mistakes in the line of delivery?
  • How does this get supported / maintained?

Working software over comprehensive documentation:

  • What are you most productive with (eg: VBA in Excel might cut it!)?
  • What are the performance / security needs (eg: can you install a runtime for .NET or Java?)
  • How rich an ecosystem do you need (eg: 3D graphics / OAuth integration)?

That said: personally I'd choose C# on .NET Core, working with VSCode :)

Collapse
 
david_j_eddy profile image
David J Eddy

Pretty much everything Phil said :).

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

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.

Collapse
 
jfrankcarr profile image
Frank Carr

VB6...

Nah, just kidding...

I'd suggest Visual Studio and C# but where to go from there really depends on the app(s) to be developed and the time frames involved.

Winforms applications can be created quickly, have near automatic backward compatibility with Windows XP to Windows 8 (if that's needed) and are quite easy to understand when written right. The problem is that it is easy to write a bad application with it and end up with a huge mess.

WPF is a little more tricky since it mostly requires writing applications using the MVVM pattern. So, if you aren't familiar with that it is a bit of a learning curve. On the flipside, if you're comfortable with separating UI from backend, this may be a good fit for you. Backwards compatibility is occasionally an issue, depending on what the app is doing. Going forward, it is likely that WPF will work better in .Net Core 3.0.

On the backend, I'd recommend developing a Web API to serve the data rather than tightly coupling the database to the application. This isn't always possible but it has become a lot more practical now. In my work in manufacturing applications, we are in the process of moving all data access to Web API, leaving only the UI and connectivity to hardware devices (barcode readers, scales, etc) to the front end.

Collapse
 
rhymes profile image
rhymes

I feel like @tux0r should have a say here :D Be kind ;-)

Collapse
 
nektro profile image
Meghan (she/her)

C# making either a WinForms or UniversalWindowsPlatform application.

Collapse
 
elcotu profile image
Daniel Coturel

Hi Tux0r, thanks for you're answer. I'm interested in the reasons or criteria oficina the recommendation. Could you please elaborate?