Results 1 to 5 of 5

Thread: Transaction Support in .NET

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Mar 2001
    Posts
    416

    Transaction Support in .NET

    Hi,

    In VB6, we usually put business logic & database update in middle-tier MTS, with the built-in support of transaction, we can commit/rollback easily.

    Now if we goes to .NET, we put business logic to assemblies and distribute to clients. If we still want to have automatic transaction support like MTS, is there any .NET equivalent?

    Should we:
    - transfer existing DCOM to / develop new component services for COM+
    - use ADO.NET's transaction support (not sure if ADO command like begintran still here)?

    Pls help.........thx a lot!!

  2. #2
    Frenzied Member Asgorath's Avatar
    Join Date
    Sep 2004
    Location
    Saturn
    Posts
    2,036
    Hi

    I would use ADO.NET , the SqlTransaction class supports the
    begintransaction, commit and rollback.

    Regards
    Jorge
    "The dark side clouds everything. Impossible to see the future is."

  3. #3
    Frenzied Member ntg's Avatar
    Join Date
    Sep 2004
    Posts
    1,448
    Hi,

    I would think that you can only benefit from a move away from DCOM. .Net provides extensive support for COM+ and there is good support for SQL transactions...and don't forget about Web services that can be used to encapsulate business logic. The right technology or mix of technologies, however, depends entirely upon the nature of the system that you're going to code as well as the current production environment - there is no "golden rule".

    I would definitely recommend "Visual Basic .Net Transactions" by Wrox if you want to get into the heart of the matter.

    Cheers,
    NTG
    "Feel the force...read the source..."
    Utilities: POPFile DebugView Process Explorer Wireshark KeePass UltraVNC Pic2Ascii
    .Net tools & open source: DotNetNuke log4Net CLRProfiler
    My open source projects: Thales Simulator EFT Calculator System Info Reporter VSS2SVN IBAN Functions
    Customer quote: "If the server has a RAID array, why should we bother with backups?"
    Programmer quote: "I never comment my code. Something that is hard to write should be impossible to comprehend."
    Ignorant quote: "I have no respect for universities, as they teach not practicle stuff, and charge money for"

  4. #4

    Thread Starter
    Hyperactive Member
    Join Date
    Mar 2001
    Posts
    416
    Hi,

    Many rumors about Web Services, especially on its performance, anyone have experience about it and can share with us?

    Over the past "n" years, ppl always talk about client-server, thin-client, and so we go for the web approach, app server, etc.

    In .NET, business logic goes back to client, and the burden of updating client appear again. Even M$ solutions like xcopy deployment, auto update, side-by-side execution, etc, we still need to install .NET framework to client, many users pulling updates from server will sure increase the network load.

    Is the roadmap of M$ will goes to .NET and the support of COM will dimmish? or it will be diversify into two streams?

    For our env, we simply put all logic on MTS / COM+, what is the benefit of upgrading to .NET except escaping from DLL Hell?

    Thx!

  5. #5
    Frenzied Member ntg's Avatar
    Join Date
    Sep 2004
    Posts
    1,448
    Hi,

    Originally posted by stm
    Many rumors about Web Services, especially on its performance, anyone have experience about it and can share with us?
    If interoperability with diverse systems is not high on your list, web services may not be a good idea.

    Originally posted by stm
    In .NET, business logic goes back to client, and the burden of updating client appear again.
    Not at all - just to give an example, with remoting it's extremely easy to isolate all business logic and put it on the server. You can still code thick clients but nothing in the .Net architecture forces you to do so. .Net is just a framework that supports loads of technologies. How you use it is up to you.

    Originally posted by stm
    Is the roadmap of M$ will goes to .NET and the support of COM will dimmish? or it will be diversify into two streams?
    I'd be willing to bet real money that MS would have already killed COM entirely if not for its very deep penetration into current products. We sure haven't seen the end of COM just yet, but I wouldn't expect serious development in this area. Take a look at the latest hot MS products - Win2K3 and Yukon SQL server. Isn't it obvious which direction the train is going to ?

    Originally posted by stm
    For our env, we simply put all logic on MTS / COM+, what is the benefit of upgrading to .NET except escaping from DLL Hell?
    I'd say that xcopy deployment and ending DLL hell are really only by-products of the framework. The idea is the whole new perspective of a programming platform that looks astonishingly identical to that of Java. I won't bother to stress particular strong points of .Net but rather I will share my personal experience. Recently I pulled together a team to code a pretty extensive system in .Net, part of the team were a hardcore VC++ ("old" studio) programmer (used C# for the project) and a greenhorn programmer who knew Java (used VB.Net for the project). The different languages didn't hinder their cooperation at all and both were able to help each other out. At the end of the project, the C# programmer told me that in order to write the same code under VC++ COM style he'd need at least an additional 30% of total time and he also felt that his code would be easier to maintain using C#. The VB programmer, although being very junior was able to productively be an equal member of the team. Both were coached into .Net a couple of months before the project started.

    In particular, if you're using VB6 I would say that there are huge benefits to be realized by switching to .Net. Is it going to be easy ? Definitely not. Can you port existing code ? Not really - although the migration wizard can help in some cases, porting will hurt really bad. Will MS put everything behind .Net and allow "old-style" studio to fade away ? Definitely. So, what you do depends upon your exact situation. If you have a specific product using VB6 and COM+ and want to keep updating/upgrading it, switching to .Net is not a bad idea at all. If you have a custom-made product used by few customers (or a single one) and you don't see an upgrade path as a possibility, .Net might not look too hot. IMVHO, you should check out .Net for new development though.

    Cheers,
    NTG
    Last edited by ntg; Oct 6th, 2004 at 03:28 PM.
    "Feel the force...read the source..."
    Utilities: POPFile DebugView Process Explorer Wireshark KeePass UltraVNC Pic2Ascii
    .Net tools & open source: DotNetNuke log4Net CLRProfiler
    My open source projects: Thales Simulator EFT Calculator System Info Reporter VSS2SVN IBAN Functions
    Customer quote: "If the server has a RAID array, why should we bother with backups?"
    Programmer quote: "I never comment my code. Something that is hard to write should be impossible to comprehend."
    Ignorant quote: "I have no respect for universities, as they teach not practicle stuff, and charge money for"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width