migrating VFP app to .net (architecture question)

migrating VFP app to .net (architecture question)

• Xaero

  This question is impossible to answer without the specifics of the Foxpro App.
  

  Any system with 80% needs a total overhaul, its sounds like its horribly designed, and I highly doubt that it is programmed in a way that you can easily just strip out a tier. Not to mention port it one with a different data structure.
  

  I think you need foxpro Expert to look at this system, and tell you what can and can’t do with it before you start ANY development
  

  Dave M.

  
  
  

• Error installing SSIS

  Why a hybrid VFP-.Net system Why not just go all VFP or all .Net

  I think you'll find web services slow compared to direct lookups of the data via business components. Unless you need to expose data to remote users, web services won't buy you much.

  
  
  

• BornToEnjoy

  SOA <> Web Services. You can centralize data without web services. But, since you have remote sites, web services may be the way to do this. VFP can fairly easily consume the .Net web services.

  Do a good analysis of the behavior you need for the middle-tier, then figure what data those behaviors need.

  
  
  

• Legyndir

  SOA is the big thing behind Windows Communication Foundation. It supports doing services via web services, RPC calls, and more. From what you've said, Web Services may be the best choioce, but without digging into more detail (ie detailed analysis of your needs), it's difficult to say.
  
  

• storm80y

  Well, I do have a fox pro "expert"; the guy that wrote the thing for the last 15 years or so. He's around, still working, and still a very smart guy. It's the classic case of a system that was started as something to throw at a problem, and had small to medium changes over a decade and a half.

  
  Fast forward to 2006, and here we are.
  
  It is going to be totally overhauled, hence my trying to figure out the best way to start. I don't really understand why begining in the way I'm talking about is so rediculous.
  
  You're right, it wont be easy or textbook, but it will happen, and it's just a question of how. But as part of that overhaul, I think there's something to be said for the fact that if I can manage to have the guy with all the experience building the app calling the data through proxy-class web services instead of locally, that I can leverage me on the sql/.net side, and him on the VFP side.

  
  
  

• SeeMe

  Using the old code base may not be the way to go. Architecting a .Net application is so radically different from the way that Fox apps have been traditionally done that I would not want to have the old code continue old habits.
  
  

• Youkoulele

  >>Unless you need to expose data to remote users, web services won't buy you much.
  
  The main thing web services would "buy" is portability and integration across the enterprise.
  
  He did mention they have multiple copies of the data they are trying to keep in sync - web services could help centralize the data again and possibly move towards SOA. I've found web services to be surprisingly fast and not too difficult to consume in a VFP client, but it's really a matter of what you're trying to do. Sure, you don't want to push 10,000+ row lookups, etc. - this is definitely a case of "it all depends...."
  A hybrid would be a good way to go if the domain "expert" is still going to be responsible for maintaining and deploying the client side components. So I would not write this off as ridiculous, but definitely recommend a complete analysis of the app.
  
  

• Justin_H

  My bet is that you would be better off just using the old code base as hints and plan on designing that sucker from scratch. Why hamper the 'r.a.d.' in .net with twisting it to fit older convoluted code bases (no slam of VFP intended).

  I also just got hired on to do something similar and I've been looking at VFP books just to allow me to be able to open up the old VFP code. I get the sinking feeling that the time I'm spending on that just won't pay off.

  Transforming and porting the data over becomes your sole issue.

  I am researching now to see if there are any third party tools to migrate VFP to SQL. Maybe we can swap emails to keep each other informed if we find anything.

  msbeal MCAD

  
  
  

• MandiG

  1) While it sounds reasonable at first IMHO you would end up with SQL scripts of your own instead of an SSIS package. But still might work with upsizing,DTS or SSIS just never worked for me.

  2) Web services are harder than VFP talking to an SQL server directly IMHO. Think that part again.

  3) Final front tier would be VFP or .Net If VFP then IMHO do not put web services into the play (unless you have a VFP expert who could work with web services easily).

  PS: "Migrating" generally ends in a total rewrite.

  
  

• dougzhoez

  I Didn’t say It is “ridiculous”
  

  All I said was to do a feasibility study. You made no mention of having any one who knew foxpro onsite, all you said was that you knew zilch (about foxpro).
  

  What does your “Expert” say

  Dave.

  
  
  

• Scott24

  Migrate what VFP code No tools that I know of. VFP database Then tool is right there in SQL (DTS).
  

• Zub

  Craig;
  
  While I would agree that an SOA doesn't specifically limit itself to web services, it's certainly one of the core methods. I'm looking at what I consider to be a defacto text on SOAs, and and the sub title is "A Field Guide to Integrating XML and Web Services."
  
  Wikipedia has pretty much the same take. Where again, you're free to implement these services however you like, but the intent is to be homogonous in your approach and end result, and XML/SOAP is easily at the head of the field for that pursuit.
  
  http://en.wikipedia.org/wiki/Service-oriented_architecture
  
  To be clear, a big reason that I'm pushing for web services and a very textbook approach to an SOA is because of the amount of data silos that currently exist here, and the fact that we need to have a high degree of transparency and integration into all of them.
  
  I'd love to hear more people on this subject, and I'd like to thank everyone (even those I disagree with) for their input. I'm seeking opinions and professional advice, and that means taking all sides into account.
  
  

• Che3324

  Randy:
  
  You hit the nail on the head. I'm a systems architect, and responsible for ensuring that when all is said and done, we have a standards based and textbook environment. If it means we work twice as hard, than that's what we have to do, to end up with a solid SOA. I'm glad you noticed that a service oriented architecture is where I might be trying to go with all of this.
  
  You also hit the nail on the head with why I want to use web services to centralize the data. All the connections back to the central office (from 15 remote sites) are done over dedicated full T1's, so there's plenty enough bandwidth to shuttle xml back and forth. 80K rows worth Probably not, but that's something we can address as we're designing. I'd be reluctant to send 80K rows across any network, let alone a WAN.
  
  One of my other reasons for this approach, aside from the technical aspect, is that this lets me leverage myself and the other .net people for the data and middle tier, and I can have the foxpro guy doing what he does best... foxpro.
  
  The middle and data tiers are what I really care about. The UI/presentation is obviously important, but I can't see it being a major bottleneck. Furthermore, once the web services are build and acting as the exclusive access to the database, then building another UI in .net is going to be a heck of a lot easier.
  
  
  
• migrating VFP app to .net (architecture question)