Application Architecture

I have an existing VB6 application that runs on in a client/server configuration on a LAN. I want to rewrite the application in .net and as it is very large I want to get the architecture right before I start.

I would like to get any advice from the experts who have worked on similar architectures.

Are there are any good books you could recommend regarding different structures on .net. I am not worried about the coding, it is the architecture.

----------------------------------

The new application must be a client/server application and be able to run on a local LAN as well as over the internet. I would like the client to be winforms, but it there are any good reasons I would change to webforms.

I would also like to only have one client interface and not one separate one for remote and another for local access.

The questions I ask are:

1.) What and where would you structure the different modules.

2.) Must I use ASP.NEt, XML and IIS etc, for both client intefaces. This would be a great overhead on the local system.

3.) Another problem is that most of my clients use Access mdb but some use SQL Server. Now I would like to use stored procedures but in the past this is not possible in both cases and I have done all the queries in the code. Is this still the best option and should I have a separate module for the queries.

Any advice would be greatly appreciated.

Quote:

---

The new application must be a client/server application and be able to run on a local LAN as well as over the internet. I would like the client to be winforms, but it there are any good reasons I would change to webforms

---

because you want to access it over the internet... and since you only want ONE client interface, you would want to use webforms... but then you have to worry about sessionState.. or you could winforms and have the clients over the internet download or have a copy of the program.... but really, I don't know the nature of your project or your clients...

As far as queries in code... you could implement webservices for that... so all the client interface would need to do is call that webservice. And the webservice would of course use a DataSet object and run its filter that way... this way if you need to add or change a query, you can do in one place.. and all the clients would use the new code.

The Access /SQL implementation dilemma is unfortunate... I couldn't tell from your post whether the access database is for your program only, but seeing as different client's have 2 diff databases, I'm guessing not... so you will have to code it yourself...

There will be loads on the server side.. but that's really the whole idea is to have one big expensive puter do the brute work and lower the cost of ownership for the other puter's...

XML is great for some things... anytime you begin using remoting or web services... you have to carefully plan how much data you will be passing over the network... and parsing XML obviously takes more time.. implementing these technologies can cause a few more debugging headaches when things don't go to plan.. and they won't...


But depending on the complexity of this application, I wouldn't shoot for the moon and involve all these new technologies... if what you wrote in vb6 works... use that model.. and use .Net technologies that actually help you simplify things...

Hi Nemaroller,

I really appreciate you tiime and advice. I believe in spending more time planning and less time coding and advice like this is invaluable.

The my customers would actually purchase the software and would be masters of their own server. So it is not you stardard web applications. The customer would have 90% of the staff in the headoffice with the server and 10 % at distributed sites.

I was a bit worried about using webservices on a Lan application and thought the overheads might be too much.

I like your advice of doing all the work at the server and my previous application does not do this and it is a hassle to make changes to the business logic and reports (using Crystal Reports).

A customer either uses Access or SQL but not both. The access customers are smaller operations.

Thanks once again

Sorry I mislead you with my initial explanation.

What I meant by one client interface, is that I do not want to support a Webforms and a Winforms interface. The customers would be able to install the client interface and part of the payment would be the number of workstation they are using.

However you have opened up a can-worms as I can see your point in that you only need to support a single interface and update one interface in webforms - instead of updating all the client interfaces individually. - This is a good idea -

Although it is not without its woes I would consider Remoting for this application. I would test a small scale Factory setup and see if it serves what you are looking for. You can then let the server handle the data and just return datasets if you so desire. That way you could easily switch between data sources at the server end. Also then biz rules could be served up as well and Remoting can work over the internet (with some security restraints). The biggests woe I'd mention is events via Remoting when a NAT router is involved, it can be done but with some work arounds. To speed things up I would use binary and TCP remoting. Another good thing about it is that it is flexiable so you could make some changes, like binary/xml, TCP/HTTP, the server address all from the application config file without recompiling or changing any code.

doesn't it use up a lot of resources passing around datasets?

Also how would you update them? Would you use a data adapters update method or pass a load of parameters to a stored procedure?

It depends on the size of the dataset, but either way the data has to move from the datasource machine to the client. You could call a block type section of code to update or what might be better would be to have the remoting server return generic IDataAdapter or whatever the root class/interface of the dataadapter and dataconnection objects are. Then it wouldn't matter to the client whether it was a SQLConnection or OLEDBConnection. Of course you could just stick with OLEDB since it can connect to both SQL and Access.

Thanks Edneeis and nswan,

I have always found that the more you know the greyer the area becomes. This is typically the way things work in software development.

I think your advise to built a factory test is very good. If I do not go into too much detail I am sure I can test most of the concepts.

So if you are using remoting, I do not know too much about it, you should be able to change between binary and xml depending on the clients location. This sounds ideal.

My previous thoughts about a webform, are out the window, as I do not want the software to run in a browser.

Thanks you advise is really great, and puts me on the right path pretty quickely.