Help Desk ticket system: Windows app vs web app [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this pos开发者_StackOverflow中文版t.

Closed 8 years ago.

Improve this question

I want to create a small helpdesk ticket control system at work, that would allow users to enter a help request ticket; these tickets would then be assigned to a technician to work on, and the technician would mark it as "FINISHED" after the job is done. The requesting user would then be able to confirm and "CLOSE" the ticket, so that a Help Desk supervisor can keep track of response times and other stats based on the ticket details. Nothing too complicated, using .NET and SQL Server.

I am not sure if I should develop this as a Web application or a Windows application. This application would be used in the plant floor, so it would have to be easily available in the LAN. But we currently host a list of Windows applications via Citrix, so deployment would not really be an issue here. I don't really have experience creating winapps from scratch (though I've modified quite a few), but it feels like a web application would not look as "solid".

What advice can readers provide that could guide me into deciding the better architecture for this purpose?

EDIT Thank you all for your thoughts! Given that this is a very simple application, I could go either way. I decided to go with a Web application, as our local Citrix setup still has some quirks that need to be fixed.

If you develop a web app you can pop it on your local intranet and your users can use either their browser within Citrix, or via the browser on their terminal.

However, if you've got the infrastructure in place, then perhaps a Windows application would be easier to develop and deploy. The only limitation with a windows application would be that if you were to move away from a Citrix environment, or were to expand to wanting to use the system externally to the plant floor, then it's harder to deploy and maintain your installations.

You can use Web Deployment with Windows applications which is quite nice as it updates itself whenever you publish a new version, however it is a bit of a faf for the users and you've no guarantees that the user will allow the update to occur. So if you had a critical update, the users could, in effect, choose to ignore it.

That's where the web application gets its bonus points. One installation and one point of access. If you update it, then all users are instantly on the latest version.

Personally, I'd go with the web application for future proofing and ease of acccess. It's slightly more work than a windows application, but the payoff usually exceeds the extra time required for the web application.

Before writing this system, I would highly recommend searching www.codeplex.com and making sure that adapting another work isn't a better choice. You may find something that is already written and meets your needs while allowing you to dig around, learn and be ready to modify when they want some new feature not already present. (I believe all projects grow if the users believe in the developer.)

If you are going to write your own and can do it in the time you have, I would highly recommend that you either go with MVC if web based, or WPF (using MVVM) if you want a desktop client. There is a definitive learning curve to either MVC or WPF with MVVM. But I believe the payoff will come. I have found changes much easier when there is a clear line between business logic and visual behavior.

Personally, in this situation I would go for a windows application - as it doesn't sound as though you've any compelling reason to invoke the complexity of web-ness (perhaps it's just me that thinks web => additional complexity). I'm sure you could create a neat little windows app. in half the time it would take to create a clunky web version of the same thing!

As a sidenote:

I really like the way Eclipse Mylyn integrates with XML-RPC. Check this architecture out for inspiration:

http://www.eclipse.org/mylyn/

If you went for a similar strategy you might start off with a simple front end (Maybe as a C# with a native GUI and augment with a web-based integration with your intranet at a later point whichever is the fastest for you to do).

In esscente a 3-tier approach where you have:

The database.
The application layer wich implements an XML communication protocol (XML-RPC is quite simple).
A front end where information fields and workflow steps are 'introspected' rather than hardcoded in the client.

Just a though, hope it helps.

Write a winform app, and distribute it over ClickOnce. It's the best way to go, IMO.

Don't rush to make this decision. In the end, the Web vs Win question is about user accessibility. Much of the processing logic for your business need is independent of the interface. Spend your up front time building the right data model and identifying the necessary processing/services that you need. A well designed DB and service layer will work with both Web and Win apps. This will also give you the best flexibility as your "product" inevitably grows. You may very well want a web interface for managers needing reporting functionality and a WinForms application if you need more advanced user processing abilities for your users. And that is when your initial design work will payoff.