If you could start again?

davewill said:

Must be web based

Accounting systems tend to have number cruncher users so lots of data grids and the like with probably a fairly PC familiar user base.  I would go Silverlight 4 if you have the time to do a GUI that may need some workarounds for LOB.  The choice of Silverlight would depend on more detailed requirements though (they just added printing in version 4 and that is pretty basic for LOB).  If not Silverlight then I would still use Windows Forms with web services over ASP.NET (only because i hate web browsers).

 

Must be .NET (C# or VB.NET)

I prefer VB.NET for readability and maintenance later but C# has come a long way in those regards.  Poll your coders and see where they want to be in 2 years.  Microsoft has stated that C# and VB.NET are coming more in line and are going to be parallel more and more as we move forward but then again every Microsoft blog, post, etc seems to be in C# first with VB as the afterthought.

Must support both SQL Server and Oracle for database

Put in a layer to protect the business logic from the database so you get the flexibility of either but anticipate needing to specialize for SQL or Oracle should one need a performance tweak or 2.  Weigh your risk with more details that you may know about the volume of data over time or in surges.  The higher the volume or data input surges the more you should protect the business layer and anticipate specialization for SQL or Oracle to get the extra performance.

Must be multilingual

System.Globalization for everything.  If someone types ".ToString" it better specify.  The bummer about this one is the defaults are the current culture so it isn't like the compiler breaks or spits a warning at you.  FxCop is good about showing the needed areas though ... with one BIG exception ... in VB.NET if you use the string concatenation "&" without a ".ToString" FxCop does NOT pick up those areas for globalization review.  That one is currently biting me.

Must be multicurrency

Lean on the cultureinfo as much as you can and if you have to deal with exchange rates you will want to abstract that layer out as well (depending on where you are getting the exchange rate info).  I think the .NET cultures will keep maturing ahead of the windows cultures based on blog posts over the past 2 years between the Windows and .NET groups.

Re: Globalization. You can continue to use .ToString() without any IFormatProvider arguments if you set the Thread's CurrentCulture based on the client's accept-language HTTP header.

W3bbo said:

Charles said:

*snip*

Silverlight is a can of worms with zero gurantees of future support, also running within a plugin within a browser kinda defeats the point. I always recommend against using platforms like these for LoB applications.

W3bbo:

 

on one hand i do feel that a large system should not be totally dependant on one tech. in this case i would not try nto build the whole system with silverlight for sure, i can see some things that html and wpf or winforms will be far better at doing but...

 

I think you may be a bit to down on SIlverlight, I think the signs are clear that MS is very much looking at this as a long term platform that I think will be around for a long time...  I see it as almost as big as the creation of .Net was back when it came out.

cpod said:

Thanks for the replies so far.

 

Yes it is a product to be sold.  Apparently here in the UK and Europe

 

It is a rewrite of an existing desktop system originally written in VB6
The company wants a "browser based system"
It needs to support both SQL Server and Oracle because the current system does and they don't want to have to force customers to have to upgrade this bit.  The current database design is, to say the least not very good and therefore is in need of an overhaul so this will happen at the same time as the rewrite

about the "browser" thing.

 

I would study with great care what they think they are going to get from that.

 

many times the folks who make that kind of mandate do not have all the facts and do not fully understand the limitations of that call.

 

I would tell them that they need to take a good look at what the system needs to do and use the things that will do that best.

 

that the web browser can for sure play a key role in the overall system but that should not force the system design in to any strange contortions that make it do something poorly just to say "it's all Browser based!"

 

I have dealt with places where this has happened and i can tell you for a fact that you can spend huge amounts of time and money and get back none of it in the end.  sometimes the best thing is to have a desktop client app for some tasks that need it.

 

for example if they will have bookkeepers or accountants or folks doing a lot of invoices the big time data entry stuff...

you can build that bit faster, with a beter user interface / UX  with less problems by using something like WinForms or WPF or SIlverlight.

 

what I would take great pains to sell them on is that the "Backbone" the "Architecture" of the system will be "Internet Based"

and that means it will use "the web" anytime that is the best tool for the job at hand.

also I would share the following:

 

"If all you have is a Hammer then everything looks like a Nail"

 

so when there is a bolt or a screw do you just pound away on it ?

or do you chnage to the right tool for that part?

 

also i would give them the Triangle:

 

"You can have any two sides but not all three at the same time"

 

Fast

Cheap

Quality

 

pick two and you have to pay dearly for the thrid one.....

 

this is *ALWAYS* true and it's always a good memne to guide things.....

 

if you want it to be high quality and fast then it will not be cheap!

if you want it Fast and Cheap then it will be buggy and not so great.

and so on....

 

 

As far as WebForms vs. SL, I'd go with what I knew the best. You don't want to spend half of your time learning SL when you could already be testing the WebForms version.