|
Oh! Terrorists! And here I thought "the effort at the Starbucks" was about getitng into the baristas pants.
|
|
|
|
|
Can I have fries with that, just got a new meaning.
|
|
|
|
|
|
|
|
|
Hmm. Maybe I'll stop in and check that out. I'm driving to Rochester today (I live in Ohio), for work next week.
Software Zen: delete this;
|
|
|
|
|
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology.  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
<italic>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
modified 1-Oct-14 5:01am.
|
|
|
|
|
My personal preference would be SQL Server, SSRS for reporting and a Winforms or WPF front-end.
Create a backup database using log shipping and for your reporting create another database using replication from which you run SSRS. That way you can keep the live data on a database that is not being hit by requests for reports.
With regards to the front end while WPF is a great technology, if you have not used it before it is going to be an incredibly steep learning curve.
It is very different to winforms and you can't really jump right in until you have understood something the fundamentals of WPF, as I have discovered.
Good luck 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
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
<italic>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 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
<italic>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?
|
|
|
|
|
Well you do need a service layer and it must be agnostic to all client platforms and something as solid as WCF (we have been using it for 5 years and we are NOT early adopters) should be in your primary selection set. I think the shiny has been rubbed off by now.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
gentlemen - shiny means new to me 
Charlie Gilley
<italic>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
|
|
|
|
|
WinForm, and because of my familiarity with DevExpress, I'd use them, but I SyncFusion's stuff seems pretty good too, from what little I've done with their controls.
Since I've chosen to skip WPF (though I have had a glancing blow with one client) my personal conundrum is shifting development entirely to the web, and all the bad and ugly that comes with it. Some of the stuff I've seen is really good, but gawd, it looks painful to really learn.
Marc
|
|
|
|
|
Like Marc, I would go for the DevExpress toolkit + WinForms.
WinForms is a mature platform and the ecosystem is big enough by far.
The DevExpress WinForms controls are wonderfully integrated into WinForms.
Aside all their controls, the DevExpress reporting tools are extremely flexible, it is a dream for a developer.
Now comes the best: Do you want to be finished with your project before lunch? Then take a look at DevExpress XAF (eXpress App Framework): You will get a perfectly designed WinForms app PLUS a perfectly looking Web App, both running before lunch.
Check it out for yourself:
Amanda explaining in 10 minutes how to build an app with DevExpress XAF[^]
|
|
|
|
|
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
<italic>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
<italic>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,
<lol>Life is 2short 2remove USB safely
|
|
|
|
|
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).
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
