Data Service Tier Dll

Ok,
Application Server = File Server.
Application Server = File Server.
Application Server = File Server.
'...
'...
'...
Got it now.

:D

Quote:

---

Originally posted by RobDog888
So the Data Service dll would have hidden methods for
connecting to the database. A generic procedure to Execute the
stored procedures and return the rsSender xml strings.

I am a little confused about the connecting part. If we want to
make the most of this, then we want only one object and have
clients using the Getobject method? So the first step is to set this
up?

---

I believe the first step is to decide on your topology. These decisions should not be made until you know the thin-ness of the client app. It sounds like your are not leaning towards the web-browser-type thin client?

Correct. The owners dont like web browser apps.
Neither does the Network Admin.

Would there be a benefit of writting this in .NET? I dont know if there
will be problems with distributing the framework. Could be a big
issue. Would be nice since I'm going to all this trouble of re-writting
it.

Quote:

---

Originally posted by RobDog888
Would there be a benefit of writting this in .NET? I dont know if there
will be problems with distributing the framework. Could be a big
issue. Would be nice since I'm going to all this trouble of re-writting
it.

---

Personally I am sticking with VB6 for now (I am in an almost identical situation as you). I could go .NET for all this inter-process, inter-machine communications, but I already know how to do everything in VB6 and I don't understand a lick of VB.NET/ASP.NET.

These are very advanced programming techniques, and I daresay the crux of the language.

How long did it take you to get to this point in skills in VB6?

How long will it take to master VB.NET to do the same stuff?

I am using VB.NET now for easy stuff like GUIs and crap. But for all this domain design complexity, I'll stick with VB6, but that doesn't mean anyone else has to.

As far as your question, I don't see .NET bringing anything extra to the table that can't get done in VB6 in the same amount of time with the same resources. The only benefit is you could spare your future the drudgery of supporting a legacy app in VB6...

Quote:

---

Originally posted by RobDog888
I want to write a dll for connecting to a SQL server so I can
re-use it on my programs. I think its correct to do it this way for
better performance. Right now I have eveything in the exe. How
can I get started making it so its generic for any server or db?

Also, would running an exe from a network share be detrimental
to performance because of all the network traffic? Better to install
the exe on every pc locally?

Thanks for any help.

---

Here is your original post, with your original intent. You clearly state you have everything in the EXE. This is the very definition of a Thick client (as opposed to a Thin client).

Yet you just got done saying that your bosses or whatever won't let you make a thin client.

They can't have it both ways. Either you go thin client, and spare yourself a ton of pain, or go thick, and you will basically be left with exactly what you got right now. A big ugly mess. Sorry to sound crude, but that's the way I see it.

I'll stick with VB6 for this re-write.

They just dont want a web browser based program for this. We
cant have it a thin client exe without going to browser based?

:(

Quote:

---

Originally posted by RobDog888
I'll stick with VB6 for this re-write.

They just dont want a web browser based program for this. We
cant have it a thin client exe without going to browser based?

:(

---

Of course you can, but then you end up writing an app very much like a web-browser and a server very much like a web-server.

Do you really want to re-write a client-type-browser and also a server?

Do ya? huh? huh? :confused:

:confused: Do I?

Quote:

---

Originally posted by RobDog888
:confused: Do I?

---

I sure the hell don't.

I'll say this. Why don't you do the whole thing with the thin web client (IE) and "real" app server (IIS) and use it as a kind of prototype.

Once everything is up and running and working you can give it to your bosses and let them evaluate it.

If they still hate it, at that point you could re-write the thin client and the web server. Let it be their choice (to spend the extra time on it). You never know, they might just take what you give them and love it. I sincerely believe you will double your design time if you don't go thin client.

I always thought that to do n-tier you didn't need to write a browser
based app?

:confused:

Quote:

---

Originally posted by RobDog888
I always thought that to do n-tier you didn't need to write a browser based app?
:confused:

---

You don't need to write one if you use one that's already made, like netscape or IE. But, if you don't use one that's already made, then you do have to write your own thin client (as well as a corresponding server).

Of course, that client does not have to be an HTML interpreter (web browser), but it will behave in very much the same way regardless how it is written.

As soon as you start placing intelligence into a thin client, you no longer have a thin client, but instead have a thick client which defeats the whole purpose of n-tier design.

Ok, now I'm completely :confused:

Quote:

---

Ok, now I'm completely :confused:

---

Quote:

---

Originally posted by RobDog888
I always thought that to do n-tier you didn't need to write a browser based app?

:confused:

---

OK, then sorry to not speak so clearly. Let me re-phrase. The above assumption is correct.

But... You 1 need to write something as the thin-client front end. You will also have to 2 write some kind of server (service) that talks to and controls that thin client. You also have to write 3 an application-type intelligence to control that server.

The thing I'm trying to impart to you, is: if you 1 use a browser as your thin client, then you don't have to write it. Nor do you have to write 2 the server - use IIS. All you have to write is 3 the intelligence to control the server (like an ASP application).

Crap I think I just said the same exact thing...:blush:

I dont agree with Dave on his views about using the Web Browser as a thin client. You are still going to have to write client side logic to control the web page interaction and server side logic to control the data access. It just makes things more difficult because you have to write everything as a stateless application, meaning you will most likely have to get rid of your business logic component and try and write this stateless... Also, you must remember that web pages are not type safe and are more difficult to debug. In fact, every aspect about writing the applications for a web browser is much more difficult.

I wrote a production planning system that used a web browser as a front end. Trust me! It is much harder! And a real mission to maintain!

Writing the app in VB6, you will not have to re-write a web server nor a web browser... Not even close. Those things only have the plumming work for server-browser communication, not the data transfer, business rules etc. that you require. In any case, you will have DCOM and COM+ that will handle your communication plumming! Thats so much better!

In terms of the tutorial, I'll get started with a simple one right now.

I think you should stick with your client->business logic->data services idea!

Here is my view on your topology.

Quote:

---

Originally posted by shunt
Here is my view on your topology.

---

How did you make those diagrams?

I drew them... with a program...
Why?

Quote:

---

Originally posted by shunt
I drew them... with a program...
Why?

---

Well I want to make a rebuttle, but I just can't do it with words anymore. I'd like to make some pictoral diagrams like you made. What program did you use?

:)

I used Visio. You can use paint if you like. I think it would be good to see some diagrams out here. I think its something that is not used enough on VB forums.

In any case, I would like to see a) how other people draw the diagrams, b) how other people model the applications.

Please, state your case! I am eager to see the knowledge and views of others out there! (0 sarcasm!)

Well, I have Visio at home, so I will install it tonight, but I won't get around to making a full diagram of my ideas until next week most likely...

I understand your disagreement, and you make valid points. But to say its more difficult to make web-controlled apps as opposed to VB6 apps deserves debate.

I agree if: the front end is unreasonably complicated.

I disagree if: the front end is elegantly simple.

I guess that will all depend on the requirements of your customer... They get the ultimate decision in the complexity of their GUI.

It is that decision that can have reprecussions throughout the rest of the entire design.

It is totally true that a web GUI is stateless. But I contend that this is a good thing. Keeping track of state creates more complexity.

It only works for the view size combo box. It looks like there
should be a navigator or some other kind of animation? Maybe its
not working on my system?

Quote:

---

Originally posted by RobDog888
It only works for the view size combo box. It looks like there
should be a navigator or some other kind of animation? Maybe its
not working on my system?

---

What?

From shunt's example. If you look in the support folder you will see
what appears to be rollover images and some other stuff.

Ya I saw alot of JS but nothing really happenned. All I did was look at the main images. I wasn't sure if there was something wrong with my system too.

Ok, I like the design but I wanted to know about the users that will
just be running the app from their workstation (internal use). Will
they be taking a performance hit any different than what it was
originally? They will not want to run the program internally
through Terminal Server.

http://www.vbforums.com/attachment.p...postid=1812793

:)

Question: Why not run the internal users on Terminal Server too?

Anyway, the terminal server in the diagram can be a workstation too. To an end user, the terminal server is a workstation.

In my opinion:
Your business objects should be statefull, providing your rules as to how objects relate, data validation etc. If you use web pages for your front end, you will not be able to use objects and classes. You will have to use Java applets or ActiveX components to accomplish that, and then...you may as well be coding a vb front end. You can try and write objects using javascript...it can be done to an extent, but it is such a mission! I've done that too. I also found that coding the rules of an object into each page of the site was also a real headache! Even if it was a copy/paste affair. One little change takes you hours upon hours to code, debug and test... That equates to $$$$$$$$$$$$!

Your data services component should be stateless, providing access to the data of the system.

On the other hand:
What does your application do? If it is a simple read data, display to user, let user edit data, save data; with very simple business rules and/or data rules, then sure...a web application will do it. In fact, chuck all design out the window and use recordsets in the asp pages to do everything. Also databind the controls to the recordset. Using Visual Studio 6 with its RAD tools, you will have the application banged out in no time!

Quote:

---

If you use web pages for your front end, you will not be able to use objects and classes. You will have to use Java applets or ActiveX components to accomplish that, and then...you may as well be coding a vb front end.

---

No. You can make dynamically generated HTML "forms" without anything special running on the client (javascript, java applet, or client-side ActiveX control).

The pages are generated via code running on the server very easily. Given the simplicity of the GUI, server-side HTML generation can be much much easier than a client-side VB app.

Granted, the GUI will have limits.

Oh, I forgot - yes, you can make Classes and Objects and use them in your web app. That's the real saving grace of crappy ASP 3.0 - the fact that it makes the server infinately extensible through the use of your own custom classes.

I'm talking about ASP code like:

VB Code:

Set myObject = Server.CreateObject("myProject.myClassThatCanDoAnything")

Our program manages client, project, task, and employee information.
So yes, there will be a bit more transactions going on than
searches.

I know you can use server.createobject, but that is server side. Your client application is not going to be able to use that object. Basically, while the user is viewing and interacting with the web page, you will not be able to use objects, unless they are java applets or vb activex's. Basically, your user is chained to simple request data, edit data, submit data.

From RobDog's description here, it looks like thats what they will be doing in any case. If there is no real process for the application then just use recordsets with data bound controls. Its a real simple solution. But if you want to do a really elegant solution, you are seriously going to battle with pure HTML/ASP!

Here is a nice article I think you guys would be interested in:
http://msdn.microsoft.com/architectu...RUD-afford.asp

Quote:

---

Originally posted by shunt
I know you can use server.createobject, but that is server side. Your client application is not going to be able to use that object. Basically, while the user is viewing and interacting with the web page, you will not be able to use objects, unless they are java applets or vb activex's. Basically, your user is chained to simple request data, edit data, submit data.

---

Agreed. That is the nature of a truly thin client. It not a glamorous GUI.

I read the CRUD article and maybe I'm tired but I didn't quite take
it all in. I think I'm getting lost. I need a client/server app design
that will be scallable for a dozen users or so with decent
performance. I would like to stay away from a browser based app
simple because we have had too many issues with them from
before.

Thanks.

Basically, the article is saying that you dont often have pure CRUD operations in the application. So, reading and writing recordsets is actually not good enough. You need to define the operations of the application and implement your database interaction behind that.

Quote:

---

I need a client/server app design
that will be scallable for a dozen users or so with decent
performance.

---

I feel that my topology, you would be able to accomplish this. I think you will get the most performance using a single instance server component with connection pooling, parameterised sql, good database design with appropriate indexes.

Quote:

---

Originally posted by RobDog888
I read the CRUD article and maybe I'm tired but I didn't quite take
it all in. I think I'm getting lost. I need a client/server app design
that will be scallable for a dozen users or so with decent
performance. I would like to stay away from a browser based app
simple because we have had too many issues with them from
before.
Thanks.

---

Try a DCOM Singleton:
http://www.vbforums.com/showthread.p...hreadid=310205

Note: The singleton pattern solves a very different problem to the one discussed in the CRUD article. But I suppose it is very relevant cos it is most likely your service layer to the db...

With the Observer-Broadcaster-Singleton pattern implementation I have been discussing, any client "hooked" into the Event chain can raise an event that an update has been made. All clients will get the message as a Raised Event.

In that scenario, your clients could then re-load the combo-box only when exactly necessary.

I cannot believe I read this entire thread.

All I have to say is ... WHAT THE HELL ARE YOU GUYS SMOKING ? :D :D :D

Ok whats so hard about this:

3 tiers:

Business Tier
Database Tier
Validation Tier

The client (exe) has no access to the db...so I can't understand how hard that it to understand? Your business logic simply accesses the db tier. Your db tier returns data back to the business tier which in turn returns it back to the exe. You probably don't need the validation tier, but you'd be amazed how helpful this can become if you have a lot of business logic rules.
The validation tier validates on your client application before sending anything to your business tier (hope that makes sense)

From a design perspective you are looking at:

[Client (EXE) ] ----> [Validate tier (check it before you even bother)]-----> [business logic tier (ok so the validation worked...now i need to perform some logic and send it to the server)] <----------------> [database tier (ill store this data and return back)]

db tier cannot touch exe, database tier has nothing to do with validation tier, db tier talks back to business logic tier vice versa. Business logic tier only gets validated but talks back to the client application via some records from methods within itself.

Rob, dont make this too difficult man, even if its your first time, draw it out on paper before you start getting too deep into it. Mind you, this is a LOT of code, however this design will pay off in the end when it comes time to maintenance.

Also Rob, the business logic dll should be very versatile. In fact you should be able to pass stored procedure names, etc when retrieving data from the database tier level. Your database doesnt have to worry about the client application at all.

In this entire scenerio you can expect that you have at least the following:

DB SERVER (SQL)
Client Machine (local host to run the application)
Application Server (this is even optional but you can register your validation and business logic tiers here).

Real simple, Woka's got some good examples, else I can write you a small employee type tier application some time soon. I've just been very busy lately.

Jon