locked
Architectural assitance required for upgrading legacy VB6 app to .Net 3.5 RRS feed

  • Question

  • Hi all,

     

    I have recently been appointed to a role at an ISV where I am effectively going to be responsible for the architecture of migrating a legacy VB6 LOB application on to the .Net platform. I will be in charge of a small team and speed (as ever) is of the essence in the change.

     

    To this end,I have been reading a lot of posts on the web, the book that backs up CSLA.NET etc, microsoft site etc and it is a lot to take in. Hence, I am now at the point where I think I need some different perspectives on my current conclusions.

     

    First a bit of background :-

    • The current application is based on a 3-tier model -
    • presentation -> handled by VB exe
    • biz logic -> some handled in application tier (DCOM) quite a lot inside of stored procedures of which there are many. the application tier has a very component based API and exposes everything

     

    The current developers of the application want to get away from using an application tier and keep trying to push for implementing via stored procedures which will be called directly via the respective GUIs. Their rationale is currently every time they have to make a change to a stored procedure they also have to make it at DCOM level and it slows them down and they would much prefer to just change the SELECT list in a stored proc in the simplistic case.

     

    I'm not so sure - hopefully someone can provide me some counterpoints - i know already are scalability and centralised validation, Also bear in mind that the nature of the business that the software is sold means that virtually every implementation requires some new data / workflow.

     

    The requirements for the new version (at the global level) are :-

    1. easy to deploy - potentially via the SaaS or Software + Services Route
    2. underlying data needs to be accessible from a fat client, web page, mobile device
    3. integerate with many legacy systems using either flat file or some other integration mechanism
    4. look modern in its GUI 

    At this moment in time my thoughts are drawing me towards the following solution:-

     

    Host the DB,DAL,BIZ logic and Service layer on the internet using a SaaS type hosting provider - customers can then navigate to a web page which will give them a:-

    • Fat client Presentation Layer in WPF deployed by ClickOnce- The WPF fat client will then connect to a Serivce Layer in WCF (called via HTTPbinding or TCPbinding dependent on whether hosted inside or outside firewall)
    • Use Windows Workflow on the server to allow the varying requirements of the customer base
    • Mobile device and web clients connect via WCF web services

    However, I am worried about this solution being way too complex to achieve. I also have reservations, in that, I don't think I would want to expose all domain objects in the solution via WCF webservices. IAs this would not have to support disconnect scenarios i'm also not sure how you best to push data changes back to the client when other users affect data at the database level.

     

    Any assitance would be greatly appreciated.

     

     

     

     

    Wednesday, March 26, 2008 3:49 PM

Answers

  • I think that if you write applications as thoughfully and clearly as you write forum posts, you have nothing to worry about!

     

    I have input on three of your questions:

    1. Should business logic be moved to the stored procedure layer?

    I have had the unfortunate experience of working with an accounting system that did this, and I have had to support a custom in-house application with most of its logic in the stored proc layer.  Both experiences were very bad.  In both cases, the logic was reasonably complicated, which resulted in stored procedures that were hugely complicated and very, very long. (One stored procedure exceeded 6,000 lines.)  SQL and T-SQL are very well suited to set-based operations, but very poor with the type of procedural and branching logic required by most business processes.  The result is very long stored procedures that are impossible to maintain.  Unit testing them is very difficult too.

     

    2. Is the proposed architecture too complicated?

    The architecture should be only as complicated as the problem being solved.  And the problem you describe, apart from the specific business domain, sounds fairly complex.  It would be a mistake to simplify an architecture that is solving a complex problem because the true complexity will not go away, it will just be spread across fewer layers.  One of the most important goals of a good architecture is separation of concerns, which actually leads to simplicity.  For example, if you have only three concerns: security, remoting, and business logic, you would want to separate them into three layers.  If you combine them into one layer you will still end up writing code for each concern, but the code will be mixed up and much more complicated than is necessary.

     

    3. Should business objects be exposed from services?

    My own preference (and a widely accepted practice) is to put business objects behind a service facade rather than exposing them directly. The service facade is an implementation of a service contract.  The service contracts are defined based on the business process.  Deciding what responsibility to put in a service is the most difficult part--if they are too granular then the business intent is lost, but if they are too encompasing then they become very complex because they have multiple responsibilities.

     

    Hope that helps.

     

     

    Wednesday, March 26, 2008 4:36 PM
  • Hi Coding2Learn,

     

    You have put exactly what we are going through right now in our company to migrate a VB6 app that has implemented in the same model as yours to .NET 3.5.  I created an application architecture similar to the one I have posted in http://gajakannan.com/netarch.aspx.

     

    One of the influential member that knows every nut and bolt of VB6/SQL2K application (founding father of current application, but has not kept up with current technology trends) in our team has come up with the almost similar solution as your developers that application should reside in the stored procs and put a wcf layer to SOA-tize the application with Winforms.  Me(I have high level knowledge of the application, but kept up with technology trends) on the other hand want to use WCF/WF/WPF and rearchitect the whole application to increase the shelf life of the application.  We have not reached an agreement yet.  We both are highly opinionated and arguably has valid pros and cons for both approaches.  I am currently proposing my team to visit MTC (Microsoft technology center) and have an architecture session under MS guidance to break the stale-mate and probably find some mid-point.  I will let you know if and when we break the stale mate and the outcome of it...

     

    I do know the answer for the following to help you out...

     

     Coding2Learn wrote:

    However, I am worried about this solution being way too complex to achieve. I also have reservations, in that, I don't think I would want to expose all domain objects in the solution via WCF webservices.

     

    Sometimes we tend to conclude that all the domain objects should be exposed via WCF.  I recommend only to expose the entities needed for your application to orchestrate smoothly without writing similar code in all layers.

     

    For example, you are building an application for an ATM, and you have common bank entities like Customer, Savings Account, Checking Account, Investment Portfolio, BranchManager, BranchTeller, etc.,

    Your ATM solution should only expose Customer, SavingsAccount, CheckingAccount in the WCF service, should not expose Investment Portfolio, BranchManager, BranchTeller, etc., because those are not the operations expected out of ATM (unless requested), because the ATM can be placed in grocery shop, gas station, movie theatre, etc.,  You dont want to be showing a BranchManager information there because it is not helpful, but you can show a CustomerService information.  In the Service Gateway layer I would inspect the message content and filter content based on role that is requesting the object.  So if a Customer object in DAL returns all Account information, the ServiceGateway will inspect the request and recognizes that it is made from ATM customer.  It would remove Investment Portfolio, Mortgage information, etc., from the response message.

     

    hope this answers your question.

    Wednesday, March 26, 2008 4:37 PM

All replies

  • I think that if you write applications as thoughfully and clearly as you write forum posts, you have nothing to worry about!

     

    I have input on three of your questions:

    1. Should business logic be moved to the stored procedure layer?

    I have had the unfortunate experience of working with an accounting system that did this, and I have had to support a custom in-house application with most of its logic in the stored proc layer.  Both experiences were very bad.  In both cases, the logic was reasonably complicated, which resulted in stored procedures that were hugely complicated and very, very long. (One stored procedure exceeded 6,000 lines.)  SQL and T-SQL are very well suited to set-based operations, but very poor with the type of procedural and branching logic required by most business processes.  The result is very long stored procedures that are impossible to maintain.  Unit testing them is very difficult too.

     

    2. Is the proposed architecture too complicated?

    The architecture should be only as complicated as the problem being solved.  And the problem you describe, apart from the specific business domain, sounds fairly complex.  It would be a mistake to simplify an architecture that is solving a complex problem because the true complexity will not go away, it will just be spread across fewer layers.  One of the most important goals of a good architecture is separation of concerns, which actually leads to simplicity.  For example, if you have only three concerns: security, remoting, and business logic, you would want to separate them into three layers.  If you combine them into one layer you will still end up writing code for each concern, but the code will be mixed up and much more complicated than is necessary.

     

    3. Should business objects be exposed from services?

    My own preference (and a widely accepted practice) is to put business objects behind a service facade rather than exposing them directly. The service facade is an implementation of a service contract.  The service contracts are defined based on the business process.  Deciding what responsibility to put in a service is the most difficult part--if they are too granular then the business intent is lost, but if they are too encompasing then they become very complex because they have multiple responsibilities.

     

    Hope that helps.

     

     

    Wednesday, March 26, 2008 4:36 PM
  • Hi Coding2Learn,

     

    You have put exactly what we are going through right now in our company to migrate a VB6 app that has implemented in the same model as yours to .NET 3.5.  I created an application architecture similar to the one I have posted in http://gajakannan.com/netarch.aspx.

     

    One of the influential member that knows every nut and bolt of VB6/SQL2K application (founding father of current application, but has not kept up with current technology trends) in our team has come up with the almost similar solution as your developers that application should reside in the stored procs and put a wcf layer to SOA-tize the application with Winforms.  Me(I have high level knowledge of the application, but kept up with technology trends) on the other hand want to use WCF/WF/WPF and rearchitect the whole application to increase the shelf life of the application.  We have not reached an agreement yet.  We both are highly opinionated and arguably has valid pros and cons for both approaches.  I am currently proposing my team to visit MTC (Microsoft technology center) and have an architecture session under MS guidance to break the stale-mate and probably find some mid-point.  I will let you know if and when we break the stale mate and the outcome of it...

     

    I do know the answer for the following to help you out...

     

     Coding2Learn wrote:

    However, I am worried about this solution being way too complex to achieve. I also have reservations, in that, I don't think I would want to expose all domain objects in the solution via WCF webservices.

     

    Sometimes we tend to conclude that all the domain objects should be exposed via WCF.  I recommend only to expose the entities needed for your application to orchestrate smoothly without writing similar code in all layers.

     

    For example, you are building an application for an ATM, and you have common bank entities like Customer, Savings Account, Checking Account, Investment Portfolio, BranchManager, BranchTeller, etc.,

    Your ATM solution should only expose Customer, SavingsAccount, CheckingAccount in the WCF service, should not expose Investment Portfolio, BranchManager, BranchTeller, etc., because those are not the operations expected out of ATM (unless requested), because the ATM can be placed in grocery shop, gas station, movie theatre, etc.,  You dont want to be showing a BranchManager information there because it is not helpful, but you can show a CustomerService information.  In the Service Gateway layer I would inspect the message content and filter content based on role that is requesting the object.  So if a Customer object in DAL returns all Account information, the ServiceGateway will inspect the request and recognizes that it is made from ATM customer.  It would remove Investment Portfolio, Mortgage information, etc., from the response message.

     

    hope this answers your question.

    Wednesday, March 26, 2008 4:37 PM