 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / COM / July 2005Question to Interfaces/Objectcatalogue
We assume, that our VB6-Project has reached the maximum numbers of Public members (the "Not enough Memory" Problem). We have an ActiveX-DLL, with many classes and every class exports a lot of Members. The classes are used in the Database-Layer and the code is completly generated with a tool. This tool creates for every Table and View in the Database a CodeModule in the ActiveX-DLL. Many Members in these Classes has identical signatures (exact 29 Members). The Implementation is different - of course. e.g.: Clear(), Save(), Load(), IsModified(), ... Our Idea is now to write an Interface "IBaseTable", which contains all these Members. The Classes implements the interface and offers only a Member "Base": ... Implements IBaseTable Public Property Base() As IBaseTable Set Base = Me End Property ... Converting the existing code would be much more easier with this Member "Base" --------------------- And now the question: We have 414 classes in the DLL. Every Class contains 29 "identical" Members. Therefore we cut down the Public Members at (414-1) x 29 = 11977 Members! Is this a correct Bill? What do you think? Thanks in advance for answers and suggestions, Peter. > We assume, that our VB6-Project has reached the maximum numbers of Public > members (the "Not enough Memory" Problem). [quoted text clipped - 32 lines] > > Peter. I am sure I don't understand exactly why you are getting "memory problems", but it is not directly related to too many public members. It is however related in the sense that your design in general, which resulted in so many public members, is conducive to producing memory problems. Merely reducing the number of members in the default interface isn't going to make a substantive change. You still have to implement the additional interfaces. In this case you will just be changing the signatures. (The code and addresses will all be there just the same.) Interface Inheritance is a technique to support polymorphism. It can simplify 'coding', but does nothing to change size. Your objects will still be bloated. Unfortunately, the original design is architecturally flawed from the beginning and using a 'code generator' merely exacerbated the problem. How can I make such a pompous remark? Simple. Because I have been there and done that. <g> This is not the forum for getting into detailed design technologies, but the following might help provide a clue and an impetus to seek out some good data access design books and articles. There are multiple ways for an OO design to 'interface' to a relational database - to over-come the impedance mismatch between the two worlds. One size does not not fit all. Your strategy to 'mirror' the tables and views with objects is merely providing a layer of indirection which leads to procedural code disguised with an OOPL wrapper. While useful for some isolated tasks, it is seldom an appropriate solution for most applications. It scales poorly (your at 414 and probably still counting), leads to vast numbers of amazingly bloated objects (memory problems), and quickly becomes a maintenance nightmare if you have frequent changes to the presentation or the database. At this point, there is little you can do, 'code-wise', with your 414 objects to improve the situation. -ralph Hi Ralph. Thank's for your answer. I see now, that an additional interface can't be the solution. It doesn't pay anything. The mechanism of Interfaces and Inheritance is quite plain to me. But I don't understand the basics of COM (I think at this point, it's neccesary to read something about that ;-). Unfortunately I have no bearing on this design of the project. Althoug the concept of generated classes is not the worst thing. In a scenario with hundreds of tables, it's not a good idea, to read from ADO Recordsets untyped. And Code like rs.Fields("OrderNumber") can't be checked by the compiler. That's a potential source of error. Of course, the generated classes can't never be part of the bussines-layer. That's absolutely clear. And that's not the circumstance in our project (fortunately !) There are a lot of additional classes and class-hierarchies, which are designed for the bussines-layer. And together with the forms, we have now this bloated Project. Unfortunately, it's designed as a monolith. We plan to remake the whole project in VB.NET or C#. But that's an enterprise for the next few years. Thank you, Peter > Hi Ralph. > [quoted text clipped - 22 lines] > Thank you, > Peter I likely came across harsher than I meant. It is the nature of this medium. IMHO, There is certainly nothing wrong with code generators - I regularly use the VB Class Builder, Rational Rose (an old one), and an amazing collection of data wizards, sed scripts, and templates. (So many that when I have to 'program' at a wild box - I often sit there for awhile wondering what to do. <g>) I was only commenting that they also have a dark side. That is simply the ability to allow one to mass-clone a bad idea. <smile> Many a time, usually around 8 or 9pm, I have had a great idea! Drew up a template, and generated an almost complete suite of marvelously, truly inspired classes, that created the objects of all objects! All before bedtime. Only to wake up the next morning, have some coffee, and then wonder - "What the H* was I thinking?". <g> -ralph > All before bedtime. > Only to wake up the next morning, have some coffee, and then > wonder - "What the H* was I thinking?". <g> : - ] I get your point very good. The same to me. In Vienna it's 11:45 p.m. and I'm sitting in front of this f*ing computer and try to find a solution for our problem. And I'm sure, there is one. But also for sure is, that I will not find it tonight. Therefore I'll go to bed now - hoping, the problem is cleaning up itself tonight < :- } Greetings, Peter |
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
|
©2009 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.