Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Anybody out there interested in talking about MS multitier dev issues? 7

Status
Not open for further replies.

johnk

MIS
Jun 3, 1999
217
US
I have a small group (6 of us) of business software developers. Since VB4 we have done nothing but OOP & DCOM. There does not seem to be a large number of folks doing this, yet it may well be the most important technology (along with CORBA) to come along in a while. Now that Microsoft has published its certification specs for Win2000 Distributed Applications it is clear that COM+ is the MS way of the future.<br>
<br>
We have learned much about DCOM, OOP & multitier - most of it the hard way. I'd love to find some more of you to exchange info and experience with.<br>
<br>
John K
 
Hi John,<br>
<br>
I am reading you correctly in that you have SQL in your data access layer. I thought the data access layer would only make calls to stored procedures, via say a command object, or is this just an optional thing. Do you use stored procedures? <br>
<br>
Trying to get a handle on this n tier stuff... <br>
<br>
C
 
We have recently had a lot of success using an n-tier design. Like Kisner & Co., we have a UI tier, a business objects tier, and a data-services tier. All of our SQL statements are completely contained in the data-services tier; even our WHERE clauses are generated in this tier based on values passed by the business objects. All of our data transmitted between the data-services tier and the business objects tier is in the form of a single string that is a direct memory copy of a user-defined type (differing for each object). By keeping these two tiers completely separated we can switch to a different database and only have to make changes to the data-services tier. This is one of the many advantages of an n-tier approach: as long as all objects maintain their interface, the business objects don't care how the data-services objects get their data from the database. Theoretically, there should be no reason why you cannot use Oracle, SQL Server, Access, or any standard DBMS.<br>
<br>
We don’t use any stored procedures. In the data-services tier, we use ADO just as we would in any normal application. The difference is that this tier is only responsible for receiving requests from the business objects, getting the appropriate data from the database, and returning that data to the business objects in the requested form. Of course, the data-services tier is also responsible for all other forms of persistence – saving, deleting, creating, etc. The business objects tier is where you apply all business rules and enforce type checking. This makes the UI a very thin client. It creates objects and calls their methods, but all of the DB processing is between the application server and the database server.<br>
<br>
I hope this makes sense and helps answer some of your questions.<br>
T<br>

 
Hi Steve/John,<br>
<br>
Thanks for the post. One question, if your application has the SQL embedded in it, does this not mean that your users have a login to the database with CRUD rights? We recently wrote a system with embedded SQL and got rapped over not using sp's, justing giving the users execute permissions. We got around it by using applicatuion security in SQL Server 7.<br>
<br>
The Duwamish example on the microsoft site has no embedded SQL just calls to sp's. How do you get round this security issue? Is it normal to have embedded SQL in the data access year? Am I understanding you correctly?<br>
<br>
Thanks,<br>
<br>
C<br>

 
Hi Calahans,<br>
<br>
I'm turning this one over to my tech group for a more detailed answer. I'll try here to give a general response.<br>
<br>
Our apps use a conventional challange/response password for entry into the app. We build a custom menu for the user based on his profile. Access to database is based on menu selections exposed to each user.<br>
<br>
All database actions are carried out by our data access module using ADO and parameterized command objects in response to parameterized requests from the application modules. Our application programmers seldom write SQL statements as such. As an example, when specifying how a recordset is to be filtered the programmer provides values as parameters which our data access module turns into Where clauses. The syntax depends on the DBMS. At this date our data access module uses providers for both Access and SQL Server. Oracle is on deck. <br>
<br>
Occassionally we allow the programmer to directly manipulate the database. They use a database neutral syntax and the statements are passed through our data access module for connections and error handling.<br>
<br>
John
 
John, Steve:<br>
Can you give us some little example code?, just to understand better what you have said...<br>
<br>
thanks, <br>
<br>
b.<br>

 
bironman,<br>
<br>
I’m sorry to say that your request for sample code is a hard one to fulfill. For example, the app I am working on right now has over 60 classes that work together to form the 'guts' of the application. While they all follow the same ideology and structure, they have different purposes and, therefore, slightly different behaviors. If you have a specific question, it might be easier to supply a piece of sample code.<br>
<br>
My suggestion to you is that if you are truly interested in researching this area of study, invest in a reliable book that can give you a good foundation. The book I based my structure on is ‘Visual Basic 6 Business Objects’ by Rockford Lhotka (<A HREF=" TARGET="_new"> ). This book was a good foundation to use to build my own structure. There were adjustments that I had to make in areas that were not accounted for using the structure in the book.<br>
<br>
I hope you take the time to look into this model. Remember that it will not likely be a smooth transition, but it will yield huge benefits.<br>
<br>
Steven M. Taylor<br>
<br>
<br>
 
I run a small company developing business apps. Three years into a one year project, we are finally seeing the light! Classes are in fact the way to go. It has required more time up front but reuse is increasing and maintenance is much easier.<br>
<br>
All development is in VB6 with ADO, Access and SQL server. The UI and data service tiers are extremely light. The business rule tier does the bulk of the work. All SQL statements are restricted to the data service tier. <br>
<br>
Response time on a small LAN is fast. We are now looking into MTS. Like you, we have experienced problems with deployment. We currently use Install Shield. <p>Richard Starck<br><a href=mailto:richard.starck@netflow-usa.com>richard.starck@netflow-usa.com</a><br><a href= > </a><br>
 
Three years? Ouch!!<br>
<br>
nTier dev so tempting - but three years?<br>
<br>
It seems an awful big &quot;up-front&quot; investment.<br>
<br>
Mike<br>
<p>Mike Lacey<br><a href=mailto:Mike_Lacey@Cargill.Com>Mike_Lacey@Cargill.Com</a><br><a href= Cargill's Corporate Web Site</a><br>
 
Mike,<br>
<br>
I think I wrote the post from Richard Stark in response to another post. Only 3 or 4 words are changed, but not the thrust of it. It is of no consequence to me, but I have no idea why he posted with his name. Maybe a slip of the mouse?<br>
<br>
Our 3 years time period was due in large part to being too early in n-tier with VB. We actually turned out some useful work in the first 4 months or so. The rest brought us up to the point of a fully routine production shop (almost).<br>
<br>
Regards, John
 
Most of the three years was due to feature creep on the part of our original customer. However, we did convert from single tier to n-tier mid stream as we realized the benefits and decided it was better to do it now than later. <p>Richard Starck<br><a href=mailto:richard.starck@netflow-usa.com>richard.starck@netflow-usa.com</a><br><a href= > </a><br>
 
I'm a strong fan of OO and the Rational Unified Process. My biggest problem getting into thin-client multi-tier stuff has been the "stateless" server. I just came from a fat client application with a deeply involved object model where state was everything, so stateless is a challenge.<br>
<br>
Another breakthrough for me was realizing that components are not object oriented. Remember you can write and use COM in C or COBOL, so how OO could that be? Your code inside a component can be as OO as you like, but the interfaces have only a very basic object flavor.<br>
<br>
The transition to OO from say CICS / COBOL is often seen as a huge hurdle. I attribute failures to make the transition to trainers who start the first OO class by saying "Everything you know is wrong. I will now tell you the only right answer." Fire these people instantly. Pure OO syntax (Smalltalk for example) is as backwards as you can get from COBOL, but most hybrid languages like C++ and Java are not so wierd. The objectives of good software design are the same and if you understood cohesion and coupling in functional decomposition in COBOL, you will get encapsulation and objects.
 
Several have commented about the high cost of entry for using multi-tier and re-use architecture. <br>
<br>
While the entry cost of time and effort is certainly more than in previous technology advances in my 4 decades of experience, keep in mind that those of us who picked it up with the initial VB offering (VB4)have suffered through the penalties early users confront. Those who get in now can benefit from our early (long and expensive) experiences.<br>
<br>
While my application development firm is in the business of selling the results of our work for profit, I remain very interested in helping others where I can, and receiving help from others where they can.<br>
<br>
JohnK
 
Hi there all COM people !<br>
<br>
I have been using MTS/VB6 for quite a while now. I first started with VB 1.0 and went from there. I have used C, C++ and recently Java to create COM objects and deploy using MTS 2.0. <br>
<br>
In the last year I along with my collegues have created a large multi-tiered system completly with VB 6/DCOM and MTS using ADO 2.1 and SQL Server 6.5/7.0. We also created browser based frontends using ASP, again hooking into COM objects on MTS.<br>
<br>
I think it is facinating, and get a real kick out of developing in VB 6, although I still keep the Java skills going. I can also say we have 150-200 users working on our systems with MTS/DCOM, so that may help in grounding a few queries.<br>
<br>
I like the idea of this chat, and think it is always useful to chat to others in this field. If I can help in anyway, or provide some tips/pitfalls we have come across or provide demo code, please ask !
 
Hello Wayneds,<br>
<br>
Welcome. It's great to have someone joining in with real industrial strength DCOM experience. My small shop has been fighting the good multi-tier fight since VB4. We now use VB6, DCOM and ADO 2.1. No C, JAVA or MTS, but our own data access module runs equally well with Access and SQL Server 7 (and, theoretically with just about any RDBMS).<br>
<br>
I'm sure you will be getting some questions. My current stumper is how to connect remote fat VB clients to local 2nd tier using DCOM over the Internet. Any info or suggestions where to look will be welcomed.<br>
<br>
JohnK
 
Steven Taylor,<br>
<br>
I have the same book you're referring to but I have the VB 5 version of it. It was interesting how they talked about the UDT and variant array for passing information between the tiers. I discovered a year or so back a nice API call that will do this for you, so you don't have to calculate the length buffer for the transfer UDT. All of the code that uses this is self maintaining, so you can add as many members to your UDT as you need and don't have to modify the existing code, short of having to use the new member or take away usage of a member that has been discontinued.<br>
<br>
I had a question specifically about the UDT's. In the book they recommend that each tier be aware of the UDT so when it gets passed from one to the other, the receiving tier knows how to reconstruct the data. Is this what you did on your end?<br>
<br>
I would also be interested in how you pass information from the Business Level to the Data Level to form parameter queries. I'm assuming it's something like a parameter array. But I would be interested in how you actually did this. I'm also assuming that you building the SQL dynmically.<br>
<br>
Another question that I'm surprised that no one has brought up at this point is the topic of enumeration. What do we do in the case where we have a combobox or listbox on the users form and we want to populate it with several records from the business object? If you actually did this, did you use the NewEnum collection they talked about in the book? Then use For/Each to actually populate the listbox or combobox? I also thought about exposing the recordset through a property of the class, but that violates almost every encapsulation rule out there! Plus, I would most likely be roughed up by someone here if I actually did that.<br>
<br>
I'm interested in how others get back multiple records from the database and how they pass them from the data layer to the business layer. What about multiple updates in the data storage mechanism?<br>
<br>
Any thoughts on this? BTW, I think this is an excellent topic!<br>
<br>
Steve Meier<br>
<A HREF="mailto:sdmeier@jcn1.com">sdmeier@jcn1.com</A>
 
JohnK,<br>
<br>
You mentioned in your post above:<br>
<br>
----------------<br>
Also, we have developed code generators which create about 80% of the lines of VB code for both the UI tier and the 2nd tier. We gain much code reuse in UI and 2nd tiers. Our 3rd tier is used without change by all or our programs and can connect efficiently with almost all databases, and even that is coded completely in VB. We are very happy with the results, particularly with the universal flexbility for the user to find data with every single data form using full query by forms, and the VB code to do that is inserted by our generators. But we are very small and our work has not been tested in a large network environment. You would be welcome to take a look.<br>
----------------<br>
<br>
I'm most curious about the 3rd tier, where you talk about how it is used 'without change by all your programs'. Also about how the business objects interact with the data layer (3rd tier). I would love to take a look at what you're doing. I have a project that I have to choose a data storage mechanism for in the VERY NEAR future and I'm in the discovery / selection process now.<br>
<br>
I would also be interested in what part of the code actually gets generated by the code generator and how you determine what it generates. I'm assuming it's rule based at this point, but would like more information. I use the Visual Modeler that comes with the Enterprise Edition of Visual Studio/Basic and it generates a lot of the shell code for us. It sounds like your generator actually puts the logic/code in the routines where as VM just create the routine name with the parameters specified and the End Sub/Function. It generates no code in between, just the skeleton code of all routines.<br>
<br>
If you get a chance, drop me a line via email. If I'm lucky you might let me pick your brain on the phone for a little bit.<br>
<br>
Thanks,<br>
<br>
Steve<br>
<A HREF="mailto:sdmeier@jcn1.com">sdmeier@jcn1.com</A><br>

 
Concerning Steve Meier post above:<br>
<br>
I responded directly to this post since much detail is involved and I needed to find our more of his specifics.<br>
<br>
Our code generators have been in operation for 3 years now and are extremely useful for UI and BS tier programs. They produce about 80% of the lines of code. They are driven by the data base schema. We hope to become a source of business applications for resellers and the generators will be part of the package.<br>
<br>
We have had very good results with our data access tier using ADO and parameterized command objects and database-specific providers to achieve database independance. Our major objective was to provide a development environment for our programmers which was not specific to any RDBMS, then be able to deploy to most any DB environment. We also achieved some very good processing speeds with our strategy of using connections. We don't know yet just how scalable this will be, but performance is quite good up to 30 workstations or so, and I feel that it will do well at least to the 100 range.<br>
<br>
We are a small development shop and our time and resources are limited. However, I would like to exchange knowledge and ideas with any serious developer as our time permits.<br>
<br>
JohnK
 
I must have died and gone to Client/Server heaven! I wish I found this forum a couple of months ago when I still had a full head of hair -- with no gray ones!!! :)<br>
<br>

 
SteveMeier, and others<br>
<br>
In case you haven't got an answer yet regarding UDTs, VB6 has the ability to use PropertyBag objects which give you great flexibility as far as modifiying the elements that are passed between tiers. A simple example would be:<br>
<br>
Dim objPB as PropertyBag<br>
Dim strData as String<br>
<br>
set objPB = new PropertyBag<br>
objPB.WriteProperty &quot;CustomerID&quot;, lngCustomerID<br>
objPB.WriteProperty &quot;CustomerName&quot;, strCustomerName<br>
strData = objPB.Contents<br>
<br>
then you pass strData as the parameter between objects. On the receiving end, you reverse the process:<br>
<br>
Dim objPB as PropertyBag<br>
Dim strData as String<br>
<br>
set objPB = new PropertyBag<br>
objPB.Contents = strData<br>
objPB.ReadProperty &quot;CustomerID&quot;, lngCustomerID<br>
objPB.ReadProperty &quot;CustomerName&quot;, strCustomerName<br>
<br>
As you can see, you can add all kinds of information to the PropertyBag, including collections.<br>
<br>
I hope this helps!<br>

 
FYI<br>
<br>
I just finished developing and deploying my first Client Server application. Coming from IBM AS/400 background, this was truely a challenge and a blessing.<br>
<br>
As with others in this thread, I based the design on Rockford Lhotka's &quot;Visual Basic 6 Business Objects&quot; book. It is a must have for anyone wanting to get started in this area. &quot;Doing Objects in Microsoft Visual Basic&quot; by Deborah Kurata is another great book -- I don't have it but skimmed through it at the book store (she has a wonderful website).<br>
<br>
Here's how my application is designed:<br>
<br>
On the user's workstation, I have the following:<br>
<br>
User Interface tier (.exe)<br>
Business Objects tier (.dll)<br>
Proxy tier (.dll)<br>
<br>
On the Application Server, I have:<br>
<br>
Data-Centric tier (ActiveX Exe) running in MTS<br>
<br>
The data itself resides on the AS/400 (DB2/400).<br>
<br>
The Proxy tier has the same interface as the Data-Centric tier (same classes and public methods). The reason for this tier is to allow us to cache fairly static data on each user's machine thus speeding up the application. In doing so, the Business Object tier (aka UI-Centric objects) stays independent of the physical data (i.e. it remains clueless as to where the data is stored or what it looks like).<br>
<br>
Although we're not using &quot;Transactions&quot; per-se, we're using MTS because it gives a great visual of the application as it is running. When something goes wrong (e.g. a user is locked up) we can see which class is stuck.<br>
<br>
I have a couple a suggestions for any developer new to this environment:<br>
<br>
- Get &quot;VB6 Business Objects&quot; and &quot;VB6 Distributed Objects&quot; by Rockford Lhotka (Wrox)<br>
<br>
- Do not start developing a production-type application until you're done reading, or at least browsing, both books. When I started developing my client's application, the &quot;Distributed Objects&quot; book wasn't out yet. When it finally came out, I made some major modifications to the Business Objects because some of the issues weren't covered in the first book (which was already near 700 pages).<br>
<br>
- In the UI tier, make sure you put error handling code in almost every subroutine and function, even when you think that nothing can go wrong in a routine. Remember Murphy's Law!!!<br>
<br>
I have some questions regarding MTS and others reporting in a multi-tier environment which I'll ask at a later time. However, if you have read this entire posting and feel that I can help in anyway, please feel free to do so. You can post it here so everyone can see it or e-mail me at <A HREF="mailto:regalsys@earthlink.net">regalsys@earthlink.net</A><br>
<br>

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top