Confronto di Visual Foxpro con .NET

There is no hard and fast rule to use another full-fledged RDBMS. Even though the latest version of Visual Foxpro can be connected to SQL Server, but I have seen very large projects still, happily, using the old DBF. With .NET you have to connect to another RDBMS and it just adds to your Setup dependency.

no non avere per connettersi a qualcosa :). Questo va bene se vuoi un accoppiamento stretto di dati / applicazioni come altri hanno menzionato. Tuttavia da un punto di vista del design, questo si rompe rapidamente quando si desidera ridimensionare l'applicazione. Cosa succede quando hai un sistema molto eterogeneo che deve interconnettersi a più piattaforme? web / desktop / mobile ecc. In questo caso disaccoppiare il codice dal data-store è la via normale.

Foxpro has built-in rich reporting capability since the time of DOS era, whereas .NET developers have to depend on Crystal Reports, SSRS or other third-party variants.

Ancora una volta, non devi dipendere da nulla. La maggior parte dei "report" sono o fogli di calcolo o pdf (inserire altro formato) . Come hai già detto, sono disponibili componenti di terze parti. La maggior parte dei progetti su cui ho lavorato utilizza soluzioni personalizzate, il riutilizzo del codice fa sì che l'investimento sia unico.

Visual Foxpro 9.0 has .NET capabilities as well. However, it is not dependent on .NET and therefore your final executable doesn't need .NET framework installed, which is again a dependency.

Se stai prendendo di mira la piattaforma Windows, questo è un argomento povero. Inoltre ci sono soluzioni che possono eseguire .NET senza bisogno di .NET runtime e.g link o di altri che uniscono tutto in un unico file eseguibile. Utilizzando silverlight / Asp.net puoi anche ospitare la tua applicazione come thin client.

I have seen very large databases of Foxpro in few major government organizations, successfully running from a long time. These organizations don't feel a need to shift to SQL Server, not because of migration risks, but because they are happy with VFP.

Molte aziende sono anche contente di COBOL, tuttavia le cose sono migliorate enormemente da allora. Quando l'opzione è disponibile per utilizzare la piattaforma tecnologica più recente, non ci sono motivi reali per utilizzare piattaforme legacy.

Se vivi in un mondo in cui un'app si accoppia strettamente allo storage e solo le relazioni relazionali fanno il lavoro, allora no, non c'è davvero molto vantaggio dal passare da VFP.

Questo mondo sta diventando sempre più piccolo. E l'ultima versione di VFP è stata rilasciata nel 2007 ed è abbastanza chiaro che la piattaforma ha ricevuto il vecchio heave-ho di Microsoft. Sicuramente non svilupperei nulla di nuovo in VFP.

D'altra parte, ci sono alcuni tipi FORTRAN e COBOL che lavorano 10 ore a settimana e guidano i porsch.

Sono stato principalmente uno sviluppatore di VFP (da FPDOS) fino a quest'anno, quindi posso capire da dove proviene.

Il problema, a quanto vedo, non è capacità. Così com'è, VFP è in grado di affrontare la maggior parte dei requisiti senza battere ciglio, a volte anche superando le alternative più popolari.

Il problema è il mercato e l'ambiente che cambia. Agli occhi della maggior parte delle persone, VFP non fa più parte dello "stack" di Microsoft. Ciò significa che i venditori saranno più resistenti col passare del tempo. Significa anche che sempre meno persone impareranno la lingua, il che significa che potresti avere problemi di supporto anche se si tratta di un'applicazione interna.

Amo i VFP e continuo a maledire i momenti casuali quando lavoro con C # e .NET, ma era qualcosa che doveva essere fatto. Attenersi a VFP avrebbe solo ritardato l'inevitabile. Prima o poi, diventerà un problema e se questo è il caso, potresti anche fare il passaggio ora.

Ho lavorato in entrambi e ci sono molte ragioni per cui VFP è meno desiderabile per creare applicazioni. Eccone alcune.

• Limitazione della dimensione della tabella di 2 GB
• Forme, codice, tutto molto strettamente associato ai dati.
• Se lo utilizzerai come un front-end per altre fonti di dati, ad esempio il server sql, allora .Net offre molta più flessibilità.
• Disponibilità di sviluppatori, ho scoperto che ci sono pochissime persone ancora sviluppate in VFP.
• E ovviamente non ci sono più versioni future rilasciate.