Given an opportunity to develop a new application, what technology would you select for the UI?
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
I wold bite the bullet now and do the front end in HTML5 / Javascript using something like KnockoutJS or angularJS Your back end would be essentially the same (I concur with the SQL Server / SSRS) but provide web services to provide / update data to the client. You then have maximum flexibility for devices to run it, have fun learning it and, using web services, still have the flexibility to use any other client too, should the fancy take you.
PooperPig - Coming Soon
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Hi, You pretty much nailed down the core technology set. Following is just some design consideration and best-practices. As a general rule, try to minimize technology surface as much as possible. Pertinent to your case it seems that the following technology set may suffice the goal; 1.1. Backend DB - Sql Server Compact Edition 4.0 (single-file based DB: easy to deploy/backup/distribute) 1.2. Business Layer - C# 4.0 (Client Profile redistributable) 1.3. Front End - WPF/XAML (.NET 4.0, the same Client Profile redistributable) 1.4. Optionally - implement data export to Excel feature for 'ad-hoc' reporting/analysis As for sample practical implementation of the aforementioned technologies, you can refer to my recently released app PaydayNY-2014 for Win 7/8 to see how it works in real life (there is a free Trial edition) PaydayNY-2014P-Pro-for-Win[^] Best regards/wishes,
Life is 2short 2remove USB safely
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Html5/JS or one of the frameworks that make it easier to develop browser based UI. Aside from cross platform cross device advantage current Microsoft UI solutions can have limited support in the future or be deprecated since Microsoft is in transition now with no clear future direction for old UI stack. You may also check other DB solutions more modern than SQL if they are more suited to solve your problem (along the lines of document DB (Mongo, Hadoop etc.) and not relational DB).
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
First of all I would approach the "conundrum" of designing a UI that is "flexible" by interviewing in-depth the significant end-users of the current system. I'd listen most carefully to their descriptions of what's easy to use, and what's tricky to use, and what's damn difficult to use with the current system. I'd ask them for their ideas, doing my best to "set them at ease" ... by building trust ... so they could come up with anything they imagined and express it. I'd do the same thing with the managers of the front-line users. I would then create sketches incorporating the end-user/manager feedback, ideas, and my own inspirations; I'd go back and show those sketches to the same folks I interviews and study their reactions. After #n iterations of the design process, I would then attempt to formalize the specifications, and constraints, on the UI, taking into account hardware, software, security, and "organizational culture." It may be obvious, but let me say it anyway: by involving others in the design phase you both build "mind-share" and positive expectations that may make acceptance of your final design easier, but you also off-load the risk of coming up with something that's a total surprise to the end-users, and which they may have real trouble accepting. Only then, would I evaluate whether to use WinForms, WPF, or the Web Stack, to implement the UI, based on criteria I'd developed in the design phase: need for scaling while preserving look-and-feel across any range of sizes (I'd go with WPF for that); need for whiz-bang graphic effects and animation (again, WPF). All this should not constrain your creative imagination: if you come up with a powerful "vision" of a radical new design that might have a steep learning-curve for current users. Well, so then you have a sales job to do with both end-users and their managers. I would certainly not start that sales job until I had a smoothly working prototype, and estimation of training costs, and eventual benefits of adoption. If the various musings above are not relevant at all to your context ... sorry :)
« I had therefore to remove knowledge, in order to make room for belief » Immanuel Kant
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Before you make any decisions, you should read what Joel says[^] about rewriting software.
Wrong is evil and must be defeated. - Jeff Ello[^]
-
First of all I would approach the "conundrum" of designing a UI that is "flexible" by interviewing in-depth the significant end-users of the current system. I'd listen most carefully to their descriptions of what's easy to use, and what's tricky to use, and what's damn difficult to use with the current system. I'd ask them for their ideas, doing my best to "set them at ease" ... by building trust ... so they could come up with anything they imagined and express it. I'd do the same thing with the managers of the front-line users. I would then create sketches incorporating the end-user/manager feedback, ideas, and my own inspirations; I'd go back and show those sketches to the same folks I interviews and study their reactions. After #n iterations of the design process, I would then attempt to formalize the specifications, and constraints, on the UI, taking into account hardware, software, security, and "organizational culture." It may be obvious, but let me say it anyway: by involving others in the design phase you both build "mind-share" and positive expectations that may make acceptance of your final design easier, but you also off-load the risk of coming up with something that's a total surprise to the end-users, and which they may have real trouble accepting. Only then, would I evaluate whether to use WinForms, WPF, or the Web Stack, to implement the UI, based on criteria I'd developed in the design phase: need for scaling while preserving look-and-feel across any range of sizes (I'd go with WPF for that); need for whiz-bang graphic effects and animation (again, WPF). All this should not constrain your creative imagination: if you come up with a powerful "vision" of a radical new design that might have a steep learning-curve for current users. Well, so then you have a sales job to do with both end-users and their managers. I would certainly not start that sales job until I had a smoothly working prototype, and estimation of training costs, and eventual benefits of adoption. If the various musings above are not relevant at all to your context ... sorry :)
« I had therefore to remove knowledge, in order to make room for belief » Immanuel Kant
You suggestion is just perfect in an ideal world...Once I had the opportunity to build some software from ground-up and went to do the interviews... After 10 weeks (and it was within time-frame) I had a UI design confirmed by all relevant person - at the next week they announced bankruptcy... I never ever since then had the opportunity to do the same...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
-
You suggestion is just perfect in an ideal world...Once I had the opportunity to build some software from ground-up and went to do the interviews... After 10 weeks (and it was within time-frame) I had a UI design confirmed by all relevant person - at the next week they announced bankruptcy... I never ever since then had the opportunity to do the same...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
While I am addicted to imagining I am free of constraints, in spite of overwhelming evidence to the contrary :) ... in this case I would assert that the method you pursued ... interviewing, design phase iteration ... like the method I advocate ... Is "real world" ! What is "ideal world" is for a programmer/designer to ignore existing "context" ... current software and its users and managers, company culture, existing hardware capabilities, learning curve for new software, etc., ... and imagine they have a tabula rasa (blank slate) on which they can create any damn thing they imagine. Do you really think your 10 weeks of design-phase was a cause of the company's bankruptcy ?
« I had therefore to remove knowledge, in order to make room for belief » Immanuel Kant
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
We need more requirements. - Will it be accessed remotely? - Will it be accessed from multiple devices? If so then some or all should be written as web services. Maybe a client app that uses backend web services, maybe a web application that uses and exposes web services. - What sort of budget do you have? SQL Server's good. For some stuff. It's expensive too. Have you thought about MariaDB (open source fork of MySQL) or MongoDB? What about Redis for caching? - Who will be working on it with you? What skillsets do they have? If it's just you then you can use all the crazy tech you want. If you need to be able to have a team backing it then don't make the specs such that finding a dev or devs who can actually work within the 50 technologies you use is impossible. C#, Javascript, PHP, SQL - all bread-and-butter technologies that are easy to hire for. Start getting crazy and you'll have to either hire specialists or invest in training up staff. - If it's a pure client-app then what OS? Windows Devs are cheap. MacOS devs may not be. - on what infrastructure will it be installed? PC? Servers? Cloud? All I'd say here is: don't limit yourself to the PC. At least allow reports to be viewed on a tablet or phone so those on call can be on call in comfort. If you can provide basic functions (like "Stop the robots!") then that's a bonus. However, the big one for me is "manufacturing system". Will it be taking orders from online systems? Will it, itself, be talking to other systems to get specs, data, machine statuses? The Internet of Things is everywhere, especially in manufacturing. Even touching on this to understand how it may affect the system you're writing will give you a headstart into the next 10 years.
cheers Chris Maunder
-
charlieg wrote:
a 40 yo manufacturing system
charlieg wrote:
reporting system: any reporting system is better than they have
They already used Crystal Reports 40 years ago? :~
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}haha - no. years ago we would have custom s/w that generated the reports. We do this now in "report systems" that work on a different abstraction layer. :)
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
Before you make any decisions, you should read what Joel says[^] about rewriting software.
Wrong is evil and must be defeated. - Jeff Ello[^]
What an excellent point... I need to go get some coffee and ponder this....
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
I am in a similar situation, where I have been asked to replace the back-end system for a company that is over 10 years old. One consideration - the company you are developing this for will have over 40 years worth of data. Do they need to keep all that data live? Or can some of it be archived? The company I am doing the re-design for is a regional restaurant chain, and their system tracks all of the sales in all locations, right down to the individual purchases made on a daily basis. So after 10 years there is a lot of legacy data that is no longer used, but still hangs around in their database, taking up a lot of space. On of the things I am putting into place is a data archiving strategy so that only the data for the last 3-5 years is kept live, but with the older data made available if necessary.
Andreas
-
What an excellent point... I need to go get some coffee and ponder this....
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
That said, there are perfectly valid reasons to start over from scratch. For example, if the legacy code is done in lisp. Anyway, depending on all those thing I don't know about your project, I would probably refactor the code into logical modules/ layers that can be easier exchanged or expanded to newer technologies, when needed, one by one. So start with planning the architecture you want, and then how to get there.
Wrong is evil and must be defeated. - Jeff Ello[^]
-
I would second Guy's recommendation. However I would use a WCF to service the data requirements and probably an OData or Json transport format. This should allow you to have 1 service and any UI can feed of it. While WPF is going to be a challenge it is well worth the effort. SQL Server and Reporting Services is really a no brainer if you have experience with them. Look into a set of UI controls, we use Telerik and are reasonably satisfied with them. There are also alternative reporting tools but I like SSRS for the service (RDL) and embedded (RDLC) formats.
Never underestimate the power of human stupidity RAH
WCF - that qualifies as shiny.
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I also would have to agree with Guy. One thing to remember is the size and loading of the system. If it's small then you'd be sweet with Guy recommendation. If it's in the large size then you'll need to start thinking of breaking it down to the various layers (both database and application). Have fun, I'm a bit jealous really..
The good news is that just about anything will be faster than what they have. I've cobbled together the system over the years, but the one thing I don't really know is where the corporation is going. There are a lot of different groups that have their oars into the production area, so the more flexible the design, the better off I'll be. It's actually exciting. I've been so long in coding/debugging for the past couple of years, being able to organize a design like this is refreshing.
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I wold bite the bullet now and do the front end in HTML5 / Javascript using something like KnockoutJS or angularJS Your back end would be essentially the same (I concur with the SQL Server / SSRS) but provide web services to provide / update data to the client. You then have maximum flexibility for devices to run it, have fun learning it and, using web services, still have the flexibility to use any other client too, should the fancy take you.
PooperPig - Coming Soon
thanks maxx, more tech to familiarize myself with. The good part is that I'll bet I can find people who can write this stuff. Ever try to find a FORTRAN programmer? Note: I know some of you are out there ;)
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I am in a similar situation, where I have been asked to replace the back-end system for a company that is over 10 years old. One consideration - the company you are developing this for will have over 40 years worth of data. Do they need to keep all that data live? Or can some of it be archived? The company I am doing the re-design for is a regional restaurant chain, and their system tracks all of the sales in all locations, right down to the individual purchases made on a daily basis. So after 10 years there is a lot of legacy data that is no longer used, but still hangs around in their database, taking up a lot of space. On of the things I am putting into place is a data archiving strategy so that only the data for the last 3-5 years is kept live, but with the older data made available if necessary.
Andreas
Andreas Mertens wrote:
On of the things I am putting into place is a data archiving strategy so that only the data for the last 3-5 years is kept live, but with the older data made available if necessary.
That is definitely a good idea! I had developed a data intensive statistic package which gathered its data from an enterprise search solution on a per query basis and found that it is also a good thing to separately store aggregates in tables on an hourly, daily, monthly and yearly basis. That makes it very speedy in creating reports. Cheers!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
-
First of all I would approach the "conundrum" of designing a UI that is "flexible" by interviewing in-depth the significant end-users of the current system. I'd listen most carefully to their descriptions of what's easy to use, and what's tricky to use, and what's damn difficult to use with the current system. I'd ask them for their ideas, doing my best to "set them at ease" ... by building trust ... so they could come up with anything they imagined and express it. I'd do the same thing with the managers of the front-line users. I would then create sketches incorporating the end-user/manager feedback, ideas, and my own inspirations; I'd go back and show those sketches to the same folks I interviews and study their reactions. After #n iterations of the design process, I would then attempt to formalize the specifications, and constraints, on the UI, taking into account hardware, software, security, and "organizational culture." It may be obvious, but let me say it anyway: by involving others in the design phase you both build "mind-share" and positive expectations that may make acceptance of your final design easier, but you also off-load the risk of coming up with something that's a total surprise to the end-users, and which they may have real trouble accepting. Only then, would I evaluate whether to use WinForms, WPF, or the Web Stack, to implement the UI, based on criteria I'd developed in the design phase: need for scaling while preserving look-and-feel across any range of sizes (I'd go with WPF for that); need for whiz-bang graphic effects and animation (again, WPF). All this should not constrain your creative imagination: if you come up with a powerful "vision" of a radical new design that might have a steep learning-curve for current users. Well, so then you have a sales job to do with both end-users and their managers. I would certainly not start that sales job until I had a smoothly working prototype, and estimation of training costs, and eventual benefits of adoption. If the various musings above are not relevant at all to your context ... sorry :)
« I had therefore to remove knowledge, in order to make room for belief » Immanuel Kant
Bill, A good point, but what they don't know is that they really need to replace this system. As I'm wrapping up some very late changes for them, partly because of how old this system is, partly because of my mgt. skills, this is somewhat of a ninja project. If I can get a system basically running without too much public involvement, then I'm halfway home. True, I may toss it all in the bin, but I have the hooks into the people that really matter - the end users. It's interesting. The mgt. team has tried to force feed a new system into the factory and production process, and it failed miserably for the exact reasons you mention - they failed to ask the end users what they need. At the end of the day, I'll have learned a lot of tech. cg
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
"I'm developing a proposal to replace a 40 yo manufacturing system with newer technology" Many of you have made excellent suggestions and points, but the architects in the group have caused me to make a tactical retreat. Being a long time developer, it's natural for me to want to play with all of the latest software tech. Example: I bought SyncFusion's control set two years ago, and I want to use it :), so I'm looking for an excuse. So, the "oooo, shiney" moment has passed - back to reality. Here's the deal - back in the late 70's this manufacturing system was designed by people that really didn't write code for a living. We're talking a couple of 100K lines of FORTRAN, no design documentation, and the developers are long gone - retired, senile or dead. Ten years ago, I was pulled in to try and move it to a PC - they actually had missing source code. But we found most of that in a guy's garage. Anyway, since then, I've been tweaking here and there and slowly unraveling the system, peeling away the layers of the onion. In that time, it's become clear to me we're dealing with a relatively simple system - but one with changes to support different customers, bug fixes, etc. This is a nod to the Joel article. He makes some valid points, but I have 200K lines of FORTRAN that simply need to go... From a business perspective, the original company has been acquired, and there is an opportunity to update this system with something that will actually integrate into the new business IT environment. As a minimum, it gives me an excuse to play with new tech. I might even screw up and convince them to pay me. The system invests a lot of code to:
- User Interface: data entry, range checking. A few good controls could handle this easily.
- Database operations: these are flat files. Processing queries the flat files and generates even more flat files. Moving the data into a database would further reduce code complexity an order of magnitude.
- Report generation: I have 1000s of lines of code that generate maybe 8 basic reports. More simplification.
- Machine file generation: this is the magic code that creates files to send to their equipment.
My driving goal is to break up this monolithic application and move it into the 21st century as a properly architected 3-tier architecture. The UI doesn't depend on the flat files, the database is independent of other sections of the code, etc. This gives me the flexibility to easily add new features in an afford
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
WinForms is the new MFC (still officially supported by MS; but not getting any care or meaningful updates). IF you're sticking with .net for the UI I'd strongly recommend WPF; since with multiple customers it's unlikely you can make Win8 a requirement. WPF may be EoL as well; but in large part that's because WPF.vNext is called Metro, so porting in the future should be less painful than any other options.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
WCF - that qualifies as shiny.
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
charlieg wrote:
WCF - that qualifies as shiny.
No, that qualifies as a solid and best practice way to access your data layer. That way all your apps can use the service to access the data; wpf, internet, mobile, etc.... Just saying. :) Edit: Didn't want to come off harsh. Just want you to know, that WCF is not shiny technology. Who is going to be developing this new system, in house software engineers or are you going to have to hire out?
