What to use?

  • Thread starter Thread starter mminnie
  • Start date Start date
M

mminnie

After years of working with legacy systems, I am not starting to
discover the .NET world. Wow. I am trying to figure out how Visual
Basic, Windows Forms, Smart Clients, and all of the other .NET
technologies work together. Here is what I want:

I want a powerful desktop application with a rich user interface to
read and write data on a local or remote server (probably using SOAP).
I also want a client application that can work online or offline in the
field on a PDA device. This PDA client application should give the
user the ability to view and edit the database information on the
remote server. If the PDA is not connected to the remote data server
via the internet or other means, a synchronization of the data would
need to be performed when it finally does get a connection to the
remote server data. I want my customers to be able to view and edit
some of the same database information from a web page. I want to share
the business logic between the desktop, PDA, and web application. I
want to be able to reuse much of the code between the three
applications.

What .NET and Visual Studio technologies fit this description?
 
As you find yourself already is Net a big box with everything but basicely
to make those things easier for you.

There are different layers upon the OS which contains beside an CLS (Net
assembly intermidiate code translater) things to help to do things easier.
The names of those layers are
Net Framework
Net Framework for Server 2003
CE Net framework for PDA's

All those share the same development tools, although you have to do it for
WindowForms, Web and PDA it in a different way.

The main developer tools (languages) are
Visual Basic Net (uses the semantic from VB but you cannot compare it with
classic VB)
C# (uses the semantic from C but yu cannot comare it with that)
C++ (uses the semantic from C++ can as well be used to make programs for not
Net)
J# (uses the semantic from Java)

(With the exception of the already mentioned C++ can they make assemblies
(DLL's) from which the result is completely (as long as they are CLS
compliant) usable between the languages as long as they are not from an
newer Net version in an older Net compiler)

All those tools use parts of the Net where the are lot of parts are beside
for IO, Forms etc.
Two main parts which has other names than their namespaces are
ASPNET (web), AdoNet (database).

One main thing there is, using Net makes developing easier and let you use
things as SOAP in an easier way. The result of that is that you can use your
time for things which you with other tools probably never would do.

I hope this gives a very basic idea

Cor
 
Hello (e-mail address removed),
After years of working with legacy systems, I am not starting to
discover the .NET world. Wow. I am trying to figure out how Visual
Basic, Windows Forms, Smart Clients, and all of the other .NET
technologies work together. Here is what I want:

I want a powerful desktop application with a rich user interface to
Click to expand...

start from there http://msdn.microsoft.com/smartclient/
read and write data on a local or remote server (probably using SOAP)
Click to expand...

You can use Pipes, WebServices, EnterpriseServices, Remoting
See there http://msdn.microsoft.com/webservices/
I also want a client application that can work online or offline in
the field on a PDA device. This PDA client application should give
http://msdn.microsoft.com/mobility/

the user the ability to view and edit the database information on the
remote server. If the PDA is not connected to the remote data server
via the internet or other means, a synchronization of the data would
need to be performed when it finally does get a connection to the
remote server data. I want my customers to be able to view and edit
some of the same database information from a web page. I want to
share the business logic between the desktop, PDA, and web
application. I want to be able to reuse much of the code between the
three applications.
Click to expand...


---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
 
SQL Server CE is a version of SQL Server that is designed to run on a PDA
and to sync it's data with a central SQL Server database on demand or when
connected. Upside is that it makes programming a lot easier. Downside is
(at least in a prior version), the handheld had to be a peer on the network
with the SQL Server, and not connected to a PC through ActiveSync.

If you want to sync through ActiveSync, there are bits in Access that allow
a database to sync up. You could then run another app on the desktop to
sync the data to the server. Depending on your application, you may want
one of these technologies. Try not to pick both... at least not at first.
The complexity can become overwhelming fast. (I designed an app just like
the one you are describing).

One other thing you can do is, if you can lose the disconnected scenario,
you can run the entire app from a web site and just provide a different
presentation for the PDA browser than for the desktop browser. This is far
simpler.

If the disconnected device can be a tablet instead of a PDA, then you should
look into using Infopath, which is one of the Office applications. It has
native connectivity with SOAP web services, presents forms in a disconnected
environment, and is excellent for syncing data when you connect, one form at
a time. It's a pretty cool tool when you dig in, but not everyone's cup of
tea. The new version (in Office 2007) if friggin cool, but the current
version has a few oddities, especially in the usability department, so if
your public release date is not tomorrow, you may want to develop to the
Office beta instead of current bits.

Hope this helps,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
Back
Top