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 post.
Closed 9 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.
Related
We have a number of small ASP.NET MVC apps. All are basically a bunch of forms which capture data and store them in a SQL Server database, usually which are then loaded through to our datawarehouse and used for reporting.
We are looking to rewrite all the small applications and apply a level of consistency and good practice to each. All the applications are fairly similar and I think from a user perspective it would be better if they seemed to be part of the same large application so we were considering merging them together in some way as part of the re-write.
Our two currently preferred options seem to be:
Create a separate portal application which will be the users point of entry to the apps. This could have 'tiles' on the homepage, one for each of the apps (which would be registered in this parent app) and could link them through to all. In this scenario all the Apps would remain in different projects and be compiled/deployed independently. This seems to have the advantage of keeping the separate so we can make changes to an app and deploy without affecting the others. I could just pull common code out into a class library? One thing that annoys me about this is that the parent app must basically use hard coded links to link to each app.
I looked into using 'areas' in ASP.NET MVC and have all the small apps as different areas in one big project. This seems kindof cleaner in my head as they are all in one place, however it has the disadvantage of requiring the whole app deployed when any of the individual ones are changed, and I have a feeling we will run into trouble after adding a number of apps in to the mix.
We have a SharePoint installation and someone suggested creating the portal type app in SharePoint... This doesn't sound like the best idea to me but am willing to consider if anyone can point out advantages to this method.
Are there any recommendations on the architecture of this? Has anyone completed similar projects in the past and something worked well/not well?
We have 4 developers and we do not expect the apps to change too much once developed (except to fix potential bugs etc.). We will however plan to add new apps to the solution as time goes on.
Thank you
MVC Areas advantage would be allowing code sharing, by refactoring the repeated redundant parts of each app to use the same infrastructure code (security, logging, data access, etc.)
But it will also mean more conflicts when merging the code initially.
Deployment concerns can be mitigated with a continuous deployment tool (there are many in the market) or if you deploy to an Azure WebApp, then deployment slots can give you a zero down time deployment.
We are faced with the problem maintaining lots of windows services.
The idea is to reorganize windows services in to class libraries and connect libraries to one master windows service. Is there a good idea ? Any advices please)
There is a framework for hosting "services" within a single Windows Service called TopShelf. You might want to consider using that. https://github.com/Topshelf/Topshelf
I am interpreting your question to be "We have tons of little Windows applications that run as services - how can we simplify them?".
In general, lots of smaller programs are better. Single monolithic applications are difficult to maintain and test; when someone needs to make a small change it can trigger catastrophic consequences for dozens of other components of the application. It can also make it impossible to change one small application without taking down the whole service, as Chris Knight comments above.
On the other hand, lots of small programs suffer from the breadth problem. You probably want to make sure all your little programs run on a consistent framework - i.e. they all log their results to the same place, they all use a standardized configuration system, and they are all managed in the same place.
I have seen situations where people write services because they need to run a task "when a particular condition happens", so they make it a constantly running service and continuously check for that condition. Is it possible that you could take some of your services and turn them into triggered launches of individual applications?
If this isn't the correct interpretation, please let me know :)
I recently launched my desktop application and it got cracked after a few days. I posted a question on stack overflow and people said that i cannot stop that. In the start of the software i cannot allow this to happen and i want a solution. So, following is what i am thinking.
Currently, I have desktop application that communicates with the web server to verify the user. Once the user is verified it saves the values in Registry. The hacker has bypassed the communication code and added fake values in registry and he can use my software now.
Now, i am planning to take some of my code from MAIN features of the software to a WEB SERVICE hosted somewhere else on a web server. Whenever the software needs to run that feature the software will give a call to the WEB SERVICE with the values in REGISTRY. I will verify those values and return the results. But if the values will not match my database then i will reject the call.
So, my questions is:
1- Do you think this solution is feasible ?
2- According to my thinking, it will make the software useless to the hacker. What do you think ?
3- Any flaws in this solution ?
You don't have to get cracked. Jeez, everybody thinks there's no solutions available to prevent piracy, but there are. Disclaimer: I work for a company (Wibu Systems) that prevents software piracy and provides license management solutions.
Here's the thing: this (like all security issues) is a highly specialized area of focus and the crackers are smarter at this than you are. They are already familiar with the different home-grown solutions people roll themselves and can crack those quickly.
Commercial solutions (ours is CodeMeter; in all fairness other companies make good solutions too like SafeNet and KeyLoc) rely on strong encryption with multiple layers of protection against key discovery. These companies have spent years developing, improving, and testing their solutions; it's unlikely you will be able to come close to the robustness and quality of such a solution on your own. I can almost guarantee you that any solution you create on your own will get cracked very quickly, unless your product is uninteresting to the crackers.
I'm not trying to create an ad here; I just want to set the record straight. Companies that traditionally got cracked constantly who switched to CodeMeter stopped getting cracked. Check out Propellerhead's Record product for a good example.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
A friend has asked me to look into developing a custom system for his taxi cab company. Currently they have no system in place at all to handle their accounts or the jobs/booking etc. Eventually there will be extras like mobile applications to book but for now i need to get a backbone system developed.
He is talking about building it all as a web app, so all the accounts information/invoices etc are all in one location (most likely on a secure dedicated server) so that the ppl in the office or himself on his tablet if hes out and about can easily see what is what etc.
Part of me for some reason is not 100% convinced this is the best idea, but it does keep it all in the same place it does mean that if for example i write something in .net it doesnt need to be installed on all the machines and he can access it all from home or his tablet.
Can anyone think or link to a study paper or something, which might suggest which way is the better way to go with this? if its a web app it will most likely be done in php/html5 (i have been learning Django but dont think my skills are all there yet) if not a web app it will most likely be Java or C# (i am in the process of learning c++ but again skills arent all there.)
tldr: C#/Java system or php/html5 web app for a taxi accounts/booking system.
If this is the wrong place to post this sort of question, deepest apologies and close accordingly
I'm a desktop dev and in this case it's probably better done in the web.
If we use C#:
we have a server and a conbecting program. c# doesnt work everywhere (though java does) but just for something relatively small like this it's past overkill. but you can have offline data (if its needed though)
web:
easy to access (just need a browser) and light
THIRD OPTION:
C# can be used to develop web applications. as sich you can make it in C# and have it be accessible through a browser. (I would choose this, but I'm a desktop dev so I guess it's normal).
I'll leave you with this, mainly post to show you theres another way.
I'm not a desktop application developer, but I will chip in my opinion. The web has come a long way and it's very easy to make web user interfaces now. The biggest benefit you will probably gain from a web application is it is operating system dependent; anyone with a web browser will be able to use it.
My opinion,
I would have set up a server in Java/C# etc with a restservice or something similar, that way you can easily combine both web and desktop applications. Get the best of both worlds :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have couple of ideas in my brain which I would like to bring out before it's too late. Basically I want to develop a web application which I could sell it to clients. So which technology shall I use to accomplish this? I have been a C and C++ software developer but it's been a very long time since I have developed one. So the things I would like to know is:
Scalability and Performance?
Easy way to develop web application in a faster manner?
Any Framework?
Application server?
and which programming language?
Usually the programming language doesn't really matter. All have their own strengths and weaknesses. All come up with their own best-practices and frameworks.
It's really up to you what's your preference. If you are coming from Microsoft C/C++ I'd use .NET, if you are from Linux world I'd use Java.
Back in the 90s Java was well known as a slow framework, however there was much of myth and the framework architecture is dramatically changed since that. Today, there is no generally slow or fast framework.
You can find thousands of sites in the web that tell you that the one or the other is faster. However, at the end of the day it depends on how you implemented your solution and how you utilized the best features of the framework.
Greets
Flo
I would suggest using C++ with CPPCMS as it's becoming stable and is precisely targeted at high performance web applications.
See if the rationale match your goals.
Build with:
C#, you'll love it (I'm also an old C++ developer)
ASP.Net MVC (Validation, caching, Spark view engine)
Any ORM having a cache layer (I prefer nhibernate)
Database with lots of allocated memory
I kinda think this is almost more like a religious problem, than a real technical issue. For almost every programming language you can find a big website that's using it.
.NET -> Microsoft
Ruby -> Twitter (yes, they have a few issues, but still)
PHP -> Facebook
Java -> Lots of finance companies
Don't know about Phyton, but I'm sure there is.
More important is a good scalable architecture. That is where Twitter kinda screwed it up it seems.
Personally I use ASP.NET. Works fine, is somewhat easy and has a nice IDE. And the market is not so fragmented. Before I used Java with Websphere. Was running on a Sergenti Sun Box, so could definitely handle a lot.
I would more see into what you can get yourself into the quickest. If you know C++ C# or Java are easy to learn.
You should take a look at ASP.NET.
Using ASP.NET has got a lot of advantages, and it is very performant. Here you've got a short list of some advantages:
ASP.NET drastically reduces the amount of code required to build large applications.
With built-in Windows authentication and per-application
configuration, your applications are
safe and secured.
It provides better performance by taking advantage of early binding,
just-in-time compilation, native
optimization, and caching services
right out of the box.
The ASP.NET framework is complemented by a rich toolbox and
designer in the Visual Studio
integrated development environment.
WYSIWYG editing, drag-and-drop server
controls, and automatic deployment are
just a few of the features this
powerful tool provides.
Provides simplicity as ASP.NET makes it easy to perform common tasks,
from simple form submission and client
authentication to deployment and site
configuration.
The source code and HTML are together therefore ASP.NET pages are
easy to maintain and write. Also the
source code is executed on the server.
This provides a lot of power and
flexibility to the web pages.
All the processes are closely monitored and managed by the ASP.NET
runtime, so that if process is dead, a
new process can be created in its
place, which helps keep your
application constantly available to
handle requests.
It is purely server-side technology so, ASP.NET code executes on the
server before it is sent to the
browser.
Being language-independent, it allows you to choose the language that
best applies to your application or
partition your application across many
languages.
ASP.NET makes for easy deployment. There is no need to register
components because the configuration
information is built-in.