• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 150
  • Last Modified:

organising vb project

I am trying to plan a project that has multiple tables with related parts

so far i have these tables

On an Add form i'm going to get the user to input

Part Number (required)
Accessory, Series,Type (optional)
Bearing,Block,Chain,Disc,DriveShaft,Gear,Roller (one required)

when this is input the program should add a new record into all the related tables

Transmission will always be updated with

Part Number
TransTypeID (Series + Type values checked - if they exist in database then get the ID for record and record it here.          Otherwise add a new record to Transmission Type + record TransTypeID here)

TransDescID (Bearing, Block etc are checked for values. If Block value entered, program checks Transmission Descriptions Table for correct TransDescID for a Block. This value is entered here. The Block Table is then updated.

So i think i have all this clear in my head. But i'm not sure how i should organise the project? Should i have a class for each of these tables. Or should i have one class that represents all Transmission parts?



Transmission

Part Number     text
Accessory     text
TransTypeID     number
TransDescID     number

Transmission Type

TransTypeID     number
Series          text
Type          text

Transmission Descriptions

TransDescID     text
Description     text

Bearing

Part Number     text
Description     text

Block

Part Number     text
Description     text

Chain

Part Number     text
Description     text

Disc

Part Number     text
Description     text

DriveShaft

Part Number     text
Description     text

Gear

Part Number     text
Description     text

Roller

Part Number     text
Description     text

0
jhaigh
Asked:
jhaigh
1 Solution
 
mdouganCommented:
Early on, it was popular to try to have a class for every table.  The idea was that the class was just a server of the data.

But, the problem with that is that it means that the programmers using the class have to have a lot more knowledge about how all the classes fit together to form the more complex "object" in this case, the transmission, and that's really more than should be required.

In a well designed application, you should encapsulate all of the stuff related to a transmission into a single class.  Bury all of the details about what tables have to be updated inside of the class.  Then, in the future, programmers using your class will just have to provide the attributes of a transmission, and your class will, behind the scenes, make sure they all get to the proper tables.

This has the added advantage that the database might change in structure, and if you just change the "implementation" (the code inside) of your class, without changing the "interface" (the public function that users of your class are calling) then it will keep from breaking all of the applications that use your class...
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now