system re-write (which tech?) | The Coffeehouse

figuerres
???

in my case it's a "shared computer" and there are not really any "per user" options and no it staff on site.
we remote in to the pc's using stuff like VNC
we have the user logins setup to be only able to run the apps we want them to run.
click once lets us push an update to about 50 -70 desktops w/o visiting each of them.
also this not inside a corp. network so we can't use the internal it tools to push updates.

there are no options in this app that one user can modify.
you just run the app login and do stuff and then close the app.

when we first setup the app we have to install it from an admin account, then hack things to get the app to show up on the limited user start menu and desktop.
then log out and log in as the limited user.
then click once updates the app just fine.

if we could flagg this app for all user install then the admin would not have to mess with stuff.

for some apps this would not be the right thing .... for some it is.

kettch

In reply to vesuvius

#Mar 13th @ 4:02 AM

It all depends on the problems that will need to be solved. I've just never found that the sync services and datasets were as flexible as I needed. It might be fine for standalone apps, but for enterprisey stuff you might as well go with the extra flexibility that the WPF model provides.

I just did a production app in WPF just to see if I could. It didn't need to handle occaisionally connected scenarios, but I used the WPF databinding stuff. I found that even though I wrote more code, I definitely had a lot more control over the process.

vesuvius
Das Glasperlenspiel

In reply to kettch

#Mar 13th @ 12:58 PM

I think you need to be a litte bit far more specific than that. A typical line enterprise app has lookup tables and data that needs to be cached client side, winforms has far less friction, and far less code, hence cheaper, that is the trade off.

What specific scerario requires that you need an additional level of control?

Do remember that the "production app" in question is a distributed application (this post), and performance is paramount. Winforms wipes the floor with WPF at present, and this is a very important facet.

I am solely answering/contributing to the problems that need to be solved by the postee, head over rather than heart.

magicalclick

In reply to AndyC

#Mar 13th @ 7:25 AM

I have yet to develope enterprised WPF app, but I have seen some of those products out there. I don't know how they do it, but they allows high customization on their product. And because they are WPF app, they are really pretty. And since it is running on .Net3.0, I don't have to think about compatibility as a customer. The apps I have seen so far are thin client. All the calulation is done on the server side.

I think WPF is definitly a good choice for enterprise solution. I have seen many solution vendors using WPF for it. And saying performance is rather pointless for enterprise thin client apps. The only thing you really really need to think about is how fast the server side, which uses no WPF no silverlight no winform. For all server-client system I have encountered, server side is the one that needs performance and roubustness.

figuerres
???

In reply to magicalclick

#Mar 13th @ 2:04 PM

Really? then you have not seen many systems....

client side perf can be a very big deal in more than a few cases.

thing is the answer is "it depends"

it depends on what the data is, what the network is, what the client pc spec is, who the users are, what kind of use (data ent, data anylis, reporting etc...)
it depends on where it's used ( in a warehouse, in a call center, in a presentation to customers)

many many many things where the right tools and tech depend on the total set of variables for that problem / solution / case.

raymond

In reply to Pace

#Mar 12th @ 6:25 AM

I was a project manager for a company with a manufacturing ERP application that was written in classic ASP.

We wrote new modules in ASP.NET with Visual Basic.Net.

The company was waiting for a customer to request a complete rewrite from Visual Basic ASP to Visual Basic.Net with ASP.NET.

I left the company, but would recommend ASP.NET using Visual Basic.Net, even though I would prefer C#.

Good luck.

magicalclick

In reply to figuerres

#Mar 13th @ 4:04 PM

Yeah it depends, but I lean toward thin client, if server side of code is not crap. I actually had really bad experience on thin client because of the consultants makes crappy intergration and customization. We are to blame as well, too much weird customization request. Still, I like thin client for simple reasons, I can track all logical activities in the activity queue. And client can't make wierd stuff when offline during process (this happens a lot on Dynamic GP heavy client). Thin client eliminates many issues with heavy client design. But yeah, the server side has to be well designed, or kaboom, whole server crawling.

kettch

In reply to vesuvius

#Mar 13th @ 1:36 PM

It was in a distributed app that allowing the automatic synching of schema and data was a problem. Our scenario added mobile devices into the equation, so synching had to be dialed in. The built in sync framework is too heavy handed. I'd have to go back and look to see which framework for syncing we tried. To update the schema it would basically delete everything, download the new schema, and then download the data. This tended to be annoying on the desktop, and painful on a mobile device. We ended up with custom code that was more granular about updating both the schema and data. We also wrote a detailed business object hierarchy which is what actually got exposed to be bound.

Like has been mentioned, "it depends". It sounds like they don't have enough of a spec written yet to be able to make a good assessment of the options. Just make sure that the overall architecture is flexible enough to make the next technological transition smoother.

figuerres
???

In reply to magicalclick

#Mar 13th @ 7:05 PM

i look for what fit's.

I really like things like SIlverlight, but in some cases you have to use desktop stuff (like point of sale printers that have special control software)
also I never see any *system* as any one part..... the desktop client i have is in many ways a "thin" client it stores zero local data and uses the server to keep in sync. it does try to not hit the server to much and tries to get as much done at one time as it can when it does hit the server.
it's updated via click-once so i update 50 or so pc's at one time with one deployment, so in that way it's like updating a silverlight app.