O/T Microsoft's .NET any opinions?
Discussion
Sorry to post this on pistonheads, but most IT forums seem to be a bit partisan...
I'm about to start a software project. Idea is to improve the performance of an application by putting a data caching component between the database engine and the business logic. This will mean ripping out one side of a business data component, and pointing it at the new data caching software.
The existing software uses COM between components and OLEDB drivers to get to the database.
Question is, what to use for the new data caching component? It'll be running on a server. Could use sockets, DCOM, some other RPC architecture ... could use it is an opportunity to start using .Net
Anyone got any opinions and experience of .Net? Do its interoperability features work? Performance? Stability? Ease of maintenance?
I'm about to start a software project. Idea is to improve the performance of an application by putting a data caching component between the database engine and the business logic. This will mean ripping out one side of a business data component, and pointing it at the new data caching software.
The existing software uses COM between components and OLEDB drivers to get to the database.
Question is, what to use for the new data caching component? It'll be running on a server. Could use sockets, DCOM, some other RPC architecture ... could use it is an opportunity to start using .Net
Anyone got any opinions and experience of .Net? Do its interoperability features work? Performance? Stability? Ease of maintenance?
I'd be interested in opinions on .NET too (and anti-MS types please restrain youselves, I'd appreciate some constructive comments).
As for data caching, is there no other way to optimise your database structure or denormalise or anything? You're entering into a complex area if you start caching. I'm glad to say my days of three tier architecture are over! Never again!
As for data caching, is there no other way to optimise your database structure or denormalise or anything? You're entering into a complex area if you start caching. I'm glad to say my days of three tier architecture are over! Never again!
Basically all .net is is COM '2' (ok thats a gross simplification but thats what it boils down to in my opinion - and if you've heard that before it's what Don Box was saying...)
Depends for this caching component what you need, if you alreaddy have an existing COM architecture that works then stick with it and write a caching component to sit in the middle (shouldn't be too tricky).. You could use this as an excuse to go .net, but it's not a reason to really..
I like .net (not used it enough in release form), only got real experience of beta1 / beta2 - then I went and left the confines of **** Computers (you can guess that one) e-commerce team and work for a consultancy so I write less software and do more design..
Must admit C# rocks though, I'm a c++ guy, but I hate messing about with low level memory management - C# takes the hassle out of C++ but still leaves most of the power of the language.. (Although someone is going to start talking about Java now - ok ok thats nice too...)
Oh and the other good thing about .net is that with C# VB is now practically irrelevant...
Depends for this caching component what you need, if you alreaddy have an existing COM architecture that works then stick with it and write a caching component to sit in the middle (shouldn't be too tricky).. You could use this as an excuse to go .net, but it's not a reason to really..
I like .net (not used it enough in release form), only got real experience of beta1 / beta2 - then I went and left the confines of **** Computers (you can guess that one) e-commerce team and work for a consultancy so I write less software and do more design..
Must admit C# rocks though, I'm a c++ guy, but I hate messing about with low level memory management - C# takes the hassle out of C++ but still leaves most of the power of the language.. (Although someone is going to start talking about Java now - ok ok thats nice too...)
Oh and the other good thing about .net is that with C# VB is now practically irrelevant...
quote:
Anyone got any opinions and experience of .Net? Do its interoperability features work? Performance? Stability? Ease of maintenance?
Haven't used it, but I have heard it described as
"C plus plus for the folks that needs to use rounded end
scissors."
More cack from Microsoft, attempting yet again
to get folks to buy into their closed world.
Why not code it up in Java and / or C plus plus ?
Then at annual contract renewal time, you can
have a chance to change vendors.
quote:VB isn't VB of old any more, its more or less a new language. You need to run all your old code through a converter and hope what comes out works. Needless to say a lot of old time VB programmers aren't happy with MS.
Oh, damn. I spent the last 3 years writing VB and now I'll be back to C-type things again? Why is VB redundant?
Try and blag the .NET beta cds off someone it'll give you a taste of what your in for.
quote:
Haven't used it, but I have heard it described as
"C plus plus for the folks that needs to use rounded end
scissors."
whats wrong with rounded end scissors (cue Ralph Wiggum jokes....) Fair comment I suppose, the way i see it is that in C++ sometimes you need the advanced features of the language (which is fine, if you're writing stuff like a low level caching component then I wouldn't use anything else!) but more often than not it would be nice to have the ease (and speed) of writing in VB but with more power.
Personal take on this move by MSft is that they are aiming to replace VB (long term) as the _main_ windows development language with C#.
Of course there will always be times where only C++ wil do. However, if you don't need the advanced features of C++ to write your app, but on't want to be hand held through everything then C# is a _lot_ better than VB.. IMHO...
This is after all my opinion, I've been writing software commercially for about 7 years, there are people on this board far more experienced than me. I was lucky enough to be part of some .net pilot work at my previous company and attended the evangelical lectures from Don Box et al (and yes he still wrote his .net in emacs...)
Hi, just a quick warning about .net beta 2. It doesn't seem to break anything, but you have to uninstall if you want the full product. On my machine (and a couple of others I've heard of) this fails horribly. I had to spend ages unpicking the registry to fix it.
On the c# / vb.net debate, I'd say they're pretty much equivalent now, so (IMO) the redundancy of one of the other is a half full / half empty type question.
On the c# / vb.net debate, I'd say they're pretty much equivalent now, so (IMO) the redundancy of one of the other is a half full / half empty type question.
Thanks for the views. Having read the Msft blurb about VB's new features (threads, structured error handling, inheritance, overloading, constructors etc) it certainly looks like the language has grown up a lot. Begs the question why you need both C# and VB.
Ted, reason for caching is the data isn't RDBMS friendly. Timeseries data, triplets (date,value,status) for 60000 timeseries, about 50 million records in total. Lots of indexing to get decent retrieval speed, but it's killing SQL Server 2000. Demands a reboot every 24hrs. Query optimiser goes bonkers and ignores indexes after a while (causing 6Gb table scan ... slooooow). Data structure very simple, so cache isn't too hard.
Ted, reason for caching is the data isn't RDBMS friendly. Timeseries data, triplets (date,value,status) for 60000 timeseries, about 50 million records in total. Lots of indexing to get decent retrieval speed, but it's killing SQL Server 2000. Demands a reboot every 24hrs. Query optimiser goes bonkers and ignores indexes after a while (causing 6Gb table scan ... slooooow). Data structure very simple, so cache isn't too hard.
quote:
Oh, damn. I spent the last 3 years writing VB and now I'll be back to C-type things again? Why is VB redundant?
I have never liked VB but written tons of it. As for C-type things...well C# is NOT like C at all really. C and even C++ are very low level languages. A good framework for C++ *does* wrap up the nonsense quite well. I must be one of the few who genuinely liked MFC.
The thing with .NET is that its Java really. But by Microsoft. You don't run code - you run interpreted p-code (not quite true its compiled JIT)...just like the Java Virtual Machine does.
The good thing about .NET is that you don't need to write Java to create .NET p-code. You can use any supported language. Microsoft have C# and VB.NET. So you CAN write VB still.
This issue is why would you...C# is tha language that the run-time library for .NET (.NET Framework) is written in and therefore C# is the language that the .NET runtime is *most sympathetic* to.
The only use I can see for VB.NET is for compiling up old VB programs. And even then you might be better off re-writing them given that its run-time library is utterly different to VB6 so you're old code won't run by and large.
quote:
Hi, just a quick warning about .net beta 2. It doesn't seem to break anything, but you have to uninstall if you want the full product. On my machine (and a couple of others I've heard of) this fails horribly. I had to spend ages unpicking the registry to fix it.
That's the other thing about Microsoft.
Don't buy anything of theirs until it's been through 2-3
releases.
Unless you want to be a beta test siite, or are on the
lunatic fringe.
quote:
The only use I can see for VB.NET is for compiling up old VB programs. And even then you might be better off re-writing them given that its run-time library is utterly different to VB6 so you're old code won't run by and large.
What's the long term upgrade path? Will all my VB need to be re-written within a couple of years (that's the whole goddamn site - no minor task)?
quote:You're talking ASP VBScript, or does the site rely on VB6 Com objects?quote:What's the long term upgrade path? Will all my VB need to be re-written within a couple of years (that's the whole goddamn site - no minor task)?
The only use I can see for VB.NET is for compiling up old VB programs. And even then you might be better off re-writing them given that its run-time library is utterly different to VB6 so you're old code won't run by and large.
Hi ATG,
There are several options you have for the RPC layer of your application.
My first comment is do not use DCOM as the protocol... this technology is a nightmare if you ever have to comunicate through a firewall. (will explain if anyone is intested... but long winded)
If a previous project, we used web servcies for the comminications layer. This proves to be very good if your client is (very) distributed from your server and it comunicates over public networks, as all the protocols used are standard and can get though most filewalls. However they are (in practice) not very quick (very wordy messages and IIS is slow).
In my current project I am using remoting. This also allows for standard protocols if needed, but also allows for smaller message sizes if needed by the use of binary formatting.
What you can then do is host your back end components in COM+ for transaction and pooling support.
If you further want to increase performance (say over low bandwidth networks) is use compression in the message handling. You can write custom server and client message syncs and then use a zip lib to compress the data on the way to and from the client/server. We have had a lot of success with this method as our target architecture is 50 sites linked to a head office via 64Kb leased lines..
Hope this has helped... If not just ignor me!! :-))
On the how good is the .NET front... my answer is very... BUT... some parts of the framework let it down, namely the winform controls which are a dodgy hack wapped around the standard ones... OK for simple things.. a nightmare for anything remotly complicated.
Lake
(.Net Consultant)
There are several options you have for the RPC layer of your application.
My first comment is do not use DCOM as the protocol... this technology is a nightmare if you ever have to comunicate through a firewall. (will explain if anyone is intested... but long winded)
If a previous project, we used web servcies for the comminications layer. This proves to be very good if your client is (very) distributed from your server and it comunicates over public networks, as all the protocols used are standard and can get though most filewalls. However they are (in practice) not very quick (very wordy messages and IIS is slow).
In my current project I am using remoting. This also allows for standard protocols if needed, but also allows for smaller message sizes if needed by the use of binary formatting.
What you can then do is host your back end components in COM+ for transaction and pooling support.
If you further want to increase performance (say over low bandwidth networks) is use compression in the message handling. You can write custom server and client message syncs and then use a zip lib to compress the data on the way to and from the client/server. We have had a lot of success with this method as our target architecture is 50 sites linked to a head office via 64Kb leased lines..
Hope this has helped... If not just ignor me!! :-))
On the how good is the .NET front... my answer is very... BUT... some parts of the framework let it down, namely the winform controls which are a dodgy hack wapped around the standard ones... OK for simple things.. a nightmare for anything remotly complicated.
Lake
(.Net Consultant)
Hi Lake ... thanks for that. Interesting stuff. My app is going on a LAN, so firewall not too much of an issue, thank god. I was involved in what sounds like a similar system to yours, where we had a sort of background DB syncing system running across 64kb lines btwn head office and lots of shops. I think we were allocated 1kb/s for the application! We too used the zipping component approach.
I assume that VB scrpt and VBA are not getting the VB.net upgrades? I can't see the benefit from getting a better object model or moving away from pure interpretation given what VBscrpt and VBA are actually used for. They would benefit from direct access to .net objects however.
I assume that VB scrpt and VBA are not getting the VB.net upgrades? I can't see the benefit from getting a better object model or moving away from pure interpretation given what VBscrpt and VBA are actually used for. They would benefit from direct access to .net objects however.
Gassing Station | General Gassing [Archive] | Top of Page | What's New | My Stuff