vb6 to Windows Forms n tier app - with todays tools/mechanisms.. RRS feed

  • Question

  • I have a client who needs to port a vb6 app. He is already using Classes for his business entities. He wants to;

    1. Port software assets into .NET

    2. Create an n-tier application

    what are the recommendations with todays tools and frameworks? Does Visual Studio 2008 add anything to consider?

    I am not asking about forms vs wpf controls. That would be evolutionary after the initial port.


    I guess a BIZ  object layer and DAL layer are pretty standard, although there are different flavors of how to do it.


    Presentation layer  (which could be switched out with an ASP.NET front end) instantiates the business object which in turn instantiates any necessary objects whose collections are hydrated after a DAL layer call to the db.


    Decision is still either databinding on the Winforms controls to either a strongly typed generic list or a dataset.


    I guess the part that is always a challenge is how to update the model, both in memory and then knowing when to persist that in memory representation of the UI controls (textboxName has just changed) back to the db.

    In a more complex UI, how does the textboxName selection or textchanged event propogate to some other control located in some other panel which needs to be updated.


    I think the Patterns and Practices CAB (Composite UI app block) is probably still too complex for most and is only applicable if building something from scratch.

    I would think that WCF is usable but an inappropriate technology for use in this pretty standard 3 tier architecture.


    Thanks for any ideas.


    Wednesday, September 26, 2007 9:07 PM

All replies

  • One can always recommend the latest and greatest, but 2008 won't be released ti Feb 28th...can your client wait that long or is willing to allow beta code be used?

    I would use WCF in any tiered scenario...your comment makes no sense.

    As to converting the project, I would recommend a rewrite, vb6 has some pecurilarities that don't port well to a managed and type safe language.
    Wednesday, September 26, 2007 9:41 PM
  • The 3 tier application layer architecture has never really been formalized in MSFT class design.  That might have something to do with the bottom line weakness of the architecture.  It is a convenient way to break down a large project into sub-layers that can be handed down to medium-sized groups.  As though there is actually a realistic separation between the layers.  Breaking it down is important to keep it manageable.  The outcome rarely is, just groups of developers screaming at each other.  If you are a mid-to-upper level manager in this process, you might fancy the idea.  If you are a peon, you'll just be victim.  Nothing you could do about that, just do what the bozz asks you to do.  If you have the option right now: run!
    Wednesday, September 26, 2007 11:02 PM
  • Thank you for your reply OmegaMan. I am really glad to hear you say my comment about WCF makes no sense. 1 1/2 years ago I remember serious problems with WSDL and XSD, getting the service and client proxies out of whack, code first stuff...but maybe the tools work well now.


    I would love it if you would comment on how it does make sense in any tiered scenario. Could we say that WCF is the transport backbone behind any architecture now? Yes or no?  Are there any published examples of a 3 tier winforms wcf example with service and data contracts?  I can't remember what the binding would be (TCP??) within the Address / Binding / Contract that would define the endpoints.

    Windows form to business layer in the same process and then from the business layer to the data layer which would be talking to a database, all on the same machine.


    I totally agree with you on the rewrite of vb6. I have just done that for another company. It has taken a year for ~25K lines of code. The upgrade wizard was helpful in parts but we know that mileage may vary depending on the code source that the upgrade wizard starts with. 


    As for release of Feb 28th...that doesn't bother me. The Visual Studio 2005 upgrade wizard can at least begin the triage of the existing code base. Beta2 is feature complete so hopefully we could at least begin, especially with the RC's on the way, to start fleshing out parts of the architecture and implementation, no?


    Thank you,


    Wednesday, September 26, 2007 11:17 PM
  • Thanks for the warning, Hans. I have no commitment to this yet. Are you speaking specifically toward WCF and its use or any 3 tier implementation, no matter how well 'crafted?'


    btw, I rediscovered as perhaps the more appropriate place for my question.


    I realize there is no realistic separation between the layers. What I have never figured out is how to elegantly (ok, just get it to work) control the state of the model from the UI into and out of the database. (When does a change get committed to the db? How does that change get propogated back to whichever other UI control may need to be updated. Maybe that's why some use Datasets bound to Winforms User Controls in a 2 tier kindofa arrangement with no complex UI like the kind that the tortuous Composite User App Block (CAB) is trying to address? Go easy on my guys..I am a peon. ..Just coming up for air.  But yes, I may get my head dunked at some point again soon. :-( 


    Wednesday, September 26, 2007 11:33 PM
  • WCF isn't just Web Services. It is also the evolution of COM+/Enterprise Services. Had the VB6 application been designed as a COM+ 3-tiered application, it's architecture could be ported to WCF without serious modifications.


    Which just made me realize .... Do you mean tiers or layers?


       A VERY common misconception is to confuse the two. Generally, an n-tier architecture is a distributed architecture where the various components (client, various server or services and database) run on different machines, or different processes on the same machine. This is the domain of COM+, Enterprise Services, .NET Remoting, WCF and Web Services.

        An n-layer architecture is one that separates functionality in layers: Presentation, Data, Service, Business etc. This is the domain of class constructs, interfaces, namespaces, design patterns like MVC and MVP etc. The layers may be packaged in the same assembly or different assemblies and typically they will run on the same process.


    Thin about this. The server component of a n-tier architecture will typically have multiple layers. It will have it's own data layer, usually a presentation layer to present a consistent API to callers and a business and/or service layer to perform its core functions.


    This is why talking about the applicability of WCF for typical n-tiered architectures sounds strange. WCF was created to address just that scenario. In fact, it is far easier to create a server object now than it was with VB6 (I've done both).


    From your comments I suspect that you are interested in a layered, not a tiered application. In this case, I would suggest that you check out the various code generators and ORMs, especially those that can reverse engineer a database to create business objects and forms. I suggest this because I suspect that your client's developers aren't familiar with object-oriented design and design patterns. Going from one language to another, changing data access mechanisms from connected ADO to disconnected ADO.NET  AND migrating from an ad-hoc design to layered design is going to be difficult. I am not sure how useful the upgrade wizard can be in such a scenarion. I would suggest an ORM like LLBLGen Pro, which can reverse engineer your database and create objects ready for databinding to form controls.

    Tuesday, October 2, 2007 7:29 AM

    Thank you Panagiotis. Yes, this would be an n-layer architecture. Thank you for your clarification.

    I have used code generators in the past.

    I'll check out LLBGen Pro.

    Thanks again.


    Tuesday, October 2, 2007 9:32 PM