Background: I have a production VB6 desktop app with about 10,000 customers. It's about 10 years old.
Here are my design objectives: I want to rewrite the whole thing and offer my customers 2 options; Desktop or Web
-The desktop version would be a VB.NET client.
-The web version would be ASP.NET MVC with all the bells and whistles including a slick mobile version (jquerymobile or perhaps Kendo)
The reasoning behind this is many customers are "old school" and a bit paranoid about having their data stored on the internet (The app is for teachers and it contains some student data, like email and phone#s).
Also, the desktop version will offer some rich features that will be a bit more awkward on the web app, like some file I/O, Outlook COM integration and printing.
I want to design it DRY however, build one DLL assembly for the business objects and have either the desktop app or the ASP website utilize it.
Are there any best practices or important guidelines for such a dual-environment approach?
Is it straight-forward to design a DLL assembly and install it either on a Windows PC, or have ASP connect to it?
Theoretically, in a good N-tier design the UI layer shouldn't matter, correct?
I came across your post, and thought I’d chime in.
For the most part, you shouldn’t have too many major issues in using one core set of ‘BizLogic’ for both the Web and Desktop if you create it as it’s own project within your solution, and have the MVC-Web and Desktop projects reference it.
However, I think you’ll want to start your analysis by first asking how you plan on handling the data, where in you wrote: ‘. . .a bit paranoid about having their data stored on the internet. . .’.
I think this is a much bigger issue/challenge in that you’re going to have to figure out and determine the following:
-Where is the data going to be stored, for both the web and desktop
-How is the data kept in-sync: web-to/from-desktop, and vice-versa
-You could consider/research: Microsoft’s ‘Sync’ framework, but it is no trivial pursuit
-Where/which datastore is the ‘master’
-and things like this…
If it were me, and in my ‘very-humble-opinion’, I would go back to your Boss/Client(s), etc. and convince them that the ‘web’, or better stated: ‘centralized-data-storage’, is really the only viable solution. There are millions of companies with websites
that display/update ‘sensitive’data, i.e.: Banks, Paypal, the list goes on – I think you’ll be able to come up with a secure solution.
If you’re not able to change their minds, than you’ll probably need to look at some type of ‘smart-client’ solution, to which I’ve provided a couple of links to some ‘old school’ sample apps that Microsoft published several years back.
Okay, so assuming you’re able to convince your ‘higher-ups’ that centralized storage is viable, here is how I might layout my solution:
/WeBeTeachers.WebMVC (pure web UI project, utilizing jQuery, HTML5, CSS, etc.)
in later phases you could also extend this to support non-pc devices, i.e.: iPad, Tablets, etc.
/WeBeTeachers.Desktop (pure PC desktop / Metro UI, and/or WPF, project)
-Getting started with Metro style apps (overviews what ‘Metro’ is)
Thank you both for your very helpful answers! I'm a new here, what an awesome forum.
visionstarter
-Where is the data going to be stored, for both the web and desktop
I need to mention too, some users are in 3rd-world countries and either totally disconnected (the app is installed with a USB thumbdrive) or occasionally-connected eg. at an internet cafe.
The app simply loads the data into VB class collections and those objects are manipulated in memory during the session, and when the app closes it writes the data back to disk. The data file is a simple JSON text file (I've tinkered with a jquerymobile mobile
app that works beautifully, the javascript gobbles up the JSON with ease). So I don't need traditional relational database CRUD functionality. It just loads the entire dataset, then dumps it back to disk when the user clicks Save.
This topology will apply as well to users who simply prefer not to store their data online no matter how much I beat them over their heads
visionstarter
If it were me, and in my ‘very-humble-opinion’, I would go back to your Boss/Client(s), etc. and convince them that the ‘web’, or better stated: ‘centralized-data-storage’, is really the only viable solution.
Great euphmism, I like ‘centralized-data-storage’.
Yes, for everyone else, I'll store the data centrally and perhaps expose a JSON REST API to fetch the data
visionstarter
/WeBeTeachers.WebMVC (pure web UI project, utilizing jQuery, HTML5, CSS, etc.)
in later phases you could also extend this to support non-pc devices, i.e.: iPad, Tablets, etc.
I think we're already there. In my experimental mobile app (used on iPhones and Androids) the HTML5 LocalStorage works great along with the cache manifest. It still works perfectly offline with no hitches whatsoever.
dotnet_nerd
0 Points
5 Posts
VB6 Refugee migrating production app to .NET
Jul 03, 2012 09:41 PM|LINK
Background: I have a production VB6 desktop app with about 10,000 customers. It's about 10 years old.
Here are my design objectives: I want to rewrite the whole thing and offer my customers 2 options; Desktop or Web
-The desktop version would be a VB.NET client.
-The web version would be ASP.NET MVC with all the bells and whistles including a slick mobile version (jquerymobile or perhaps Kendo)
The reasoning behind this is many customers are "old school" and a bit paranoid about having their data stored on the internet (The app is for teachers and it contains some student data, like email and phone#s).
Also, the desktop version will offer some rich features that will be a bit more awkward on the web app, like some file I/O, Outlook COM integration and printing.
I want to design it DRY however, build one DLL assembly for the business objects and have either the desktop app or the ASP website utilize it.
Are there any best practices or important guidelines for such a dual-environment approach?
Is it straight-forward to design a DLL assembly and install it either on a Windows PC, or have ASP connect to it?
Theoretically, in a good N-tier design the UI layer shouldn't matter, correct?
vb6
ignatandrei
All-Star
137649 Points
22143 Posts
Moderator
MVP
Re: VB6 Refugee migrating production app to .NET
Jul 04, 2012 02:36 AM|LINK
And practically too.
Look ata ViewModel for MVC
http://msprogrammer.serviciipeweb.ro/2010/03/29/asp-net-mvc-orm-and-viewmodels/
and the same for a DOS application
http://msprogrammer.serviciipeweb.ro/2010/07/05/asp-net-mvc-and-dos-re-using-the-viewmodels/
visionstarte...
Member
2 Points
1 Post
Re: VB6 Refugee migrating production app to .NET
Jul 04, 2012 03:32 AM|LINK
Hey dotnet_nerd,
I came across your post, and thought I’d chime in.
For the most part, you shouldn’t have too many major issues in using one core set of ‘BizLogic’ for both the Web and Desktop if you create it as it’s own project within your solution, and have the MVC-Web and Desktop projects reference it.
However, I think you’ll want to start your analysis by first asking how you plan on handling the data, where in you wrote: ‘. . .a bit paranoid about having their data stored on the internet. . .’.
I think this is a much bigger issue/challenge in that you’re going to have to figure out and determine the following:
-Where is the data going to be stored, for both the web and desktop
-How is the data kept in-sync: web-to/from-desktop, and vice-versa
-You could consider/research: Microsoft’s ‘Sync’ framework, but it is no trivial pursuit
-Where/which datastore is the ‘master’
-and things like this…
If it were me, and in my ‘very-humble-opinion’, I would go back to your Boss/Client(s), etc. and convince them that the ‘web’, or better stated: ‘centralized-data-storage’, is really the only viable solution. There are millions of companies with websites that display/update ‘sensitive’data, i.e.: Banks, Paypal, the list goes on – I think you’ll be able to come up with a secure solution.
If you’re not able to change their minds, than you’ll probably need to look at some type of ‘smart-client’ solution, to which I’ve provided a couple of links to some ‘old school’ sample apps that Microsoft published several years back.
Okay, so assuming you’re able to convince your ‘higher-ups’ that centralized storage is viable, here is how I might layout my solution:
/WeBeTeachers_All (top-level solution)
/WeBeTeachers.DbModel (data/entity framework project)
/WeBeTeachers.BizLogic (core biz-logic project, utilizing WCF)
/WeBeTeachers.WebMVC (pure web UI project, utilizing jQuery, HTML5, CSS, etc.)
in later phases you could also extend this to support non-pc devices, i.e.: iPad, Tablets, etc.
/WeBeTeachers.Desktop (pure PC desktop / Metro UI, and/or WPF, project)
-Getting started with Metro style apps (overviews what ‘Metro’ is)
http://msdn.microsoft.com/en-us/library/windows/apps/br211386.aspx
Links to 'smart-client' sample/starter apps:
-Smart Client Sample: FotoVision
http://www.microsoft.com/en-us/download/details.aspx?id=105
-Smart Client Sample: Task Vision
http://windowsclient.net/downloads/folders/applications/entry1266.aspx
I hope this helps, and I'd be interested in hearing about what your final solution looks like.
dotnet_nerd
0 Points
5 Posts
Re: VB6 Refugee migrating production app to .NET
Jul 04, 2012 12:33 PM|LINK
Thank you both for your very helpful answers! I'm a new here, what an awesome forum.
I need to mention too, some users are in 3rd-world countries and either totally disconnected (the app is installed with a USB thumbdrive) or occasionally-connected eg. at an internet cafe.
The app simply loads the data into VB class collections and those objects are manipulated in memory during the session, and when the app closes it writes the data back to disk. The data file is a simple JSON text file (I've tinkered with a jquerymobile mobile app that works beautifully, the javascript gobbles up the JSON with ease). So I don't need traditional relational database CRUD functionality. It just loads the entire dataset, then dumps it back to disk when the user clicks Save.
This topology will apply as well to users who simply prefer not to store their data online no matter how much I beat them over their heads
Great euphmism, I like ‘centralized-data-storage’.
Yes, for everyone else, I'll store the data centrally and perhaps expose a JSON REST API to fetch the data
I think we're already there. In my experimental mobile app (used on iPhones and Androids) the HTML5 LocalStorage works great along with the cache manifest. It still works perfectly offline with no hitches whatsoever.
Thanks again for your input