xmen64
09-27-2004, 06:55 PM
Help!
I want to get more experience programming in COM. I have a project coming up involving graphics, serial communication, Access database, and winsock.
Please give me ideas on what portion I can separate as COM.
I am new to COM, but I understand the concept. I created simple COM programs (based on book examples). I want to learn more!
Thanks!
Mark Micallef
09-27-2004, 07:57 PM
Help!
I want to get more experience programming in COM. I have a project coming up involving graphics, serial communication, Access database, and winsock.
Please give me ideas on what portion I can separate as COM.
I am new to COM, but I understand the concept. I created simple COM programs (based on book examples). I want to learn more!
Thanks!
IMHO, there are two import concepts at play here:
1. A technology (Component Object Model, or COM); and
2. A design pattern (n-tier architecture)
My advice, decide first how you want to split up the application. The convention is to use three layers:
1. Data
2. Logic (often referred to as "Business Logic" since the model is often used for business apps)
3. Presentation
This gives you a nice, easy way to split up your application. I would suggest you start by creating a DB access helper class (I use one called "DBHelper") in your COM library with simple methods such as runSQLreturnRS() to run a SQL command and return a recordset and runSQL() to execute a command. Also have a think about how you're going to manage the DB connection. If your app is stateful (eg, a standard windows app), it might suit your design to open your connection when the application starts, and close it when the app terminates. In a stateless programming environment (eg, web application), you would logically open and close the connection with every request (but would actually implement COM+ connection pooling under the hood so there would be a pool of persistant connections the system would draw upon).
In the next layer up, start breaking you app up into logical classes. For example, in a inventory management type app, you might have "data" classes like AssetLine, Supplier, etc... You might also have classes which apply logic to the data classes (this is a lightweight pseudo-example of Model-View-Controller (MVC) design pattern, which fits nicely with the n-tier pattern, but can be a little difficult to implement properly in VB, which is not fully OO).
I would *STRONGLY* suggest that you concern your more with the design of the application from a technology-agnostic viewpoint first, before committing yourself to specific technologies. You woul be wise to make use of modelling tools and methodologies like UML as much as possible. You may also want to review the classic "Design Patterns" by Gamma et al (http://www.amazon.com/exec/obidos/ASIN/0201633612/qid=1096336283/sr=ka-1/ref=pd_ka_1/103-9883460-7560621), heavy going but well worth it. Remember, coding is the easy part of any project, as long as the design is right!
Hope this helps.
Cheers,
Mark
xmen64
09-27-2004, 08:45 PM
IMHO, there are two import concepts at play here:
1. A technology (Component Object Model, or COM); and
2. A design pattern (n-tier architecture)
My advice, decide first how you want to split up the application. The convention is to use three layers:
1. Data
2. Logic (often referred to as "Business Logic" since the model is often used for business apps)
3. Presentation
This gives you a nice, easy way to split up your application. I would suggest you start by creating a DB access helper class (I use one called "DBHelper") in your COM library with simple methods such as runSQLreturnRS() to run a SQL command and return a recordset and runSQL() to execute a command. Also have a think about how you're going to manage the DB connection. If your app is stateful (eg, a standard windows app), it might suit your design to open your connection when the application starts, and close it when the app terminates. In a stateless programming environment (eg, web application), you would logically open and close the connection with every request (but would actually implement COM+ connection pooling under the hood so there would be a pool of persistant connections the system would draw upon).
In the next layer up, start breaking you app up into logical classes. For example, in a inventory management type app, you might have "data" classes like AssetLine, Supplier, etc... You might also have classes which apply logic to the data classes (this is a lightweight pseudo-example of Model-View-Controller (MVC) design pattern, which fits nicely with the n-tier pattern, but can be a little difficult to implement properly in VB, which is not fully OO).
I would *STRONGLY* suggest that you concern your more with the design of the application from a technology-agnostic viewpoint first, before committing yourself to specific technologies. You woul be wise to make use of modelling tools and methodologies like UML as much as possible. You may also want to review the classic "Design Patterns" by Gamma et al (http://www.amazon.com/exec/obidos/ASIN/0201633612/qid=1096336283/sr=ka-1/ref=pd_ka_1/103-9883460-7560621), heavy going but well worth it. Remember, coding is the easy part of any project, as long as the design is right!
Hope this helps.
Cheers,
Mark
Thanks Mark!
That database COM object sounds like something I will implement.
Any other suggestions folks?
-xmen64