 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / VB.NET / April 2007Developing for EXE and ASP
Could someone give me a few bullet point notes on how I go about developing a system that can be deployed both as an ASP intranet as well as a stand alone EXE. In essence we are aiming to provide both ASP/EXE to our clients, but to try an minimise the amount of development work involved with maintaining the applications. This would take over from a standard ASP Intranet and stand-alone Access applications (of course, the latter being a key decision to make this move). The development would be completed with VB.Net and/or Visual Studio .NET Regards, Sean On Apr 10, 11:32 am, "Sean" <sean.anderson@[nospam]oakleafgroup.biz> wrote: > Could someone give me a few bullet point notes on how I go about developing > a system that can be deployed both as an ASP intranet as well as a stand [quoted text clipped - 11 lines] > > Sean ASP or ASP.Net? Thanks, Seth Rowe > On Apr 10, 11:32 am, "Sean" <sean.anderson@[nospam]oakleafgroup.biz> > wrote: [quoted text clipped - 22 lines] > > Seth Rowe Proposed solution would be in .NET as I understand that it's possible to have a .NET solution that could be deployed as both ASP.NET (for the Intranet) and VB.NET (for the stand-alone application). > Could someone give me a few bullet point notes on how I go about > developing a system that can be deployed both as an ASP intranet as well [quoted text clipped - 11 lines] > > Sean Well, this is one thing n-tier applications allow. What you need to do (if you go this route) is to create ui-independent business and data logic layers that contain most of your non-ui code. The Business Logic layer provides the actual business logic (data validation, massaging, etc) while the Data Access layer provides the meat for accessing (fetch/update/delete/insert) of the data into the data store. You still need to write two apps in this case... Another way would be to make your app an HTML application (with the .hta extension). This makes a single UI that can be used from Internet Explorer but downloads and runs as an application. I've gone this route before, but we did have hurdles/hoops to jump through. HTH, Mythran >> Could someone give me a few bullet point notes on how I go about >> developing a system that can be deployed both as an ASP intranet as well [quoted text clipped - 28 lines] > HTH, > Mythran So, with the HTML application there's one UI ... one set of code, etc., ? This sounds like what we could be looking for. Will investigate further. If you have any pointers for getting me started, would appreciate it. Could you advise of what development environment you would use. > So, with the HTML application there's one UI ... one set of code, etc., ? Yes and no... UI - 2 sets of code (ASP.NET/WinForms/PDA/etc) Business Logic - one set (deployed on app server or as DLL) Data Layer - one set (deployed as DLL, on app server, or on data base server). > This sounds like what we could be looking for. Will investigate further. > > If you have any pointers for getting me started, would appreciate it. > > Could you advise of what development environment you would use. We use VS.NET 2005. LLBLGen Pro is a great Data Layer Generator - saves hand coding the data layer (DLs are very redundant to code). > Could someone give me a few bullet point notes on how I go about > developing a system that can be deployed both as an ASP intranet as > well as a stand alone EXE. You have two main options: 1. Create the back end logic as a web service - this way all clients will use the same logic for all critical functions (i.e. save, retrieve, etc). 2. Or place your application logic into a DLL... and use the DLL as the foundation for your application (ASP, Desktop, etc). Problem with #2 is that if a client has an outdated EXE... it's going to use outdated logic. Also if you're deploying to hundreds of clients... it could be a pain to update. So it depends on how much logic you wish to keep control over ... but web services is definately a consideration for your situation. >> Could someone give me a few bullet point notes on how I go about >> developing a system that can be deployed both as an ASP intranet as [quoted text clipped - 14 lines] > So it depends on how much logic you wish to keep control over ... but web > services is definately a consideration for your situation. #1 isn't possible as not all clients have a webserver that we can utilise. For updates, there are (at most) only a handful of data entry clerks that would use the stand-alone application and they're all in the same department so easy to update. Seems like a n-tier is the way to go, but from what I have read here (and the other replies), I don't see a benefit here from using .NET and DLL's over writing a solution with VB, ASP and DLL's. With the steep learning curve that we will encounter on .NET ... seems to make sense to stick with VB/ASP as this is well trodden ground from which there will be far fewer hurdles/hoops to deal with. > #1 isn't possible as not all clients have a webserver that we can > utilise. So where are you storing the data? Directly to SQL server? Couldn't you just as easily deploy a web server? > For updates, there are (at most) only a handful of data entry clerks > that would use the stand-alone application and they're all in the same [quoted text clipped - 3 lines] > (and the other replies), I don't see a benefit here from using .NET > and DLL's over writing a solution with VB, ASP and DLL's. n-tier is definately the way to go, but typically you'll need an application server as the middle tier... and without a web server, you don't have n-tiers. > With the > steep learning curve that we will encounter on .NET ... seems to make > sense to stick with VB/ASP as this is well trodden ground from which > there will be far fewer hurdles/hoops to deal with. .NET is entirely OO which makes for easy maintainance. ASP.NET has a nice event model which makes programming complex web apps MUCH easier than ASP. Also VB/ASP is considered obsolete, so your app is already obsoleted. But if your team has significant learning to jump to .NET ... then yes, it can be a pain. But it's the sort of pain you'll need to take sooner or later? Perhaps this isn't the project to do so ... but you should definately consider moving your team to .NET. The benefits of .NET will be apparently once you move :-) >> Seems like a n-tier is the way to go, but from what I have read here >> (and the other replies), I don't see a benefit here from using .NET [quoted text clipped - 3 lines] > application server as the middle tier... and without a web server, you > don't have n-tiers. I should take the last comment back. I was thinking of SOA not n-tiers :-) >> #1 isn't possible as not all clients have a webserver that we can >> utilise. > > So where are you storing the data? Directly to SQL server? > Couldn't you just as easily deploy a web server? For those that don't have a SQL server, they work with an Access DB stored on a shared folder. Deploying a web server would be wonderful ... but, they wouldn't allow us to do it. > .NET is entirely OO which makes for easy maintainance. ASP.NET has a > nice event model which makes programming complex web apps MUCH easier > than ASP. Also VB/ASP is considered obsolete, so your app is already > obsoleted. The standalone application is an Access application ... so, yes we know about obsolete. > But if your team has significant learning to jump to .NET ... then yes, > it can be a pain. But it's the sort of pain you'll need to take sooner > or later? Perhaps this isn't the project to do so ... but you should > definately consider moving your team to .NET. The benefits of .NET will > be apparently once you move :-) Good point, perhaps a starter with a smaller project ... difficult as we only really have this set of applications (our primary product) and a development team of two. Sean, First you have to ask yourself if your clients trust you. (Let say the same as you trust Microsoft as it is about the Word Program). If that is the fact, you don't need an HTML (by you called ASP) program, you can supply everybody a nice EXE program in the same way as Microsoft does it with word by using the inbuild Click Once deployment method. Cor > Could someone give me a few bullet point notes on how I go about > developing a system that can be deployed both as an ASP intranet as well [quoted text clipped - 11 lines] > > Sean > Sean, > [quoted text clipped - 7 lines] > > Cor Trust with our clients isn't an issue, it's a bespoke system that is bought on contractual terms with all the why's and wherefore's for security clearly detailed in the contracts. The project (as it presently stands) is in two parts, because of a few details: (1) Data entry is carried out (primarily) from one department of a big organisation. -- Either solution is viable (2) Not all clients have a Web Server (or not one that we can utilise). -- Only a stand-alone is viable (3) Some clients wish to share data (in read-only format) to others in the organisation. -- Known prerequisite for an Intranet. I am not sure what you mean by "the inbuild Click Once deployment method" ? > I am not sure what you mean by "the inbuild Click Once deployment > method" ? Click one is a deployment method in .NET 2.0 (supports auto-download, auto- update, etc). However, I believe Click-Once needs a web server which you don't have. BTW, is there a reason your clients don't have access to a web server? I noticed your clients need to send read-only data files which are sent through your Intranet? >> I am not sure what you mean by "the inbuild Click Once deployment >> method" ? [quoted text clipped - 7 lines] > noticed your clients need to send read-only data files which are sent > through your Intranet? Not all have a webserver, some do, which is a growing number (thankfully). Our standalone application has a readonly mode which is used when they don't have a webserver, but in this environment the total deployment is much smaller than when they have a webserver, but it's also fairly true that when there is a need for a wider range deployment, the organisation is proportionally bigger and more technologically up to date, with a webserver and usually SQL. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.