I am fairly new to object oriented programming. I have developed a few usercontrols for an IT Asset Tracking System that I am developing but I need some good advice on the coding side of things as I am using VB 2005 Professional.
What kind of classes and objects do I need to create for my system within VB 2005. So far as an example, I have the following tables in my SQL Server 2005 express database as I am fine with the db side of things:
OperatingSystem - Lookup table for operating systems
HardDrive - Lookup table for hard drive sizes
CPUSpeed - Lookup table for CPUSPeed
MemorySize - Lookup table for System memory
WarrantyCompany - Lookup table for warranty companies
ProductListing - List of products to add to purchase orders
AssetDetails - Full details of asset such as PC, Server, Printer etc. Will have an AssetID as PK and the lookup tables as FK
AssetCategory - Whether it is Computer, Printer etc
AssetType - If computer, is it Desktop PC, Notebook or Server. If Printer, is it Laser, Dot Matrix etc
PurchaseOrders - To store purchase order details
If someone can advise me in the right direction then this would be a great help.
Why not create objects (classes) which match your physical objects?
For example, you can have an AssetObject which has an ID Number.
Then you may have a ComputerObject which inherits from the AssetObject which has OS, HDD, CPU, etc.
The PrinterObject, once again Inheriting from the AssetObject, has a PrinterType, etc.
you could have a Dictionary or list of AssetObjects.
This is just a suggestion for a starting point - you may want to think about anything that may happen in the future which may 'break' the structure you implement.
Thanks for your reply. I know that you have assisted me on other issues before.
Is it possible to show me an example VB representation of this class you have described as I should then be able to grasp why the implementation has to be done this way.
I have already created a document which details the activities that will take place in the Inventory side of the Asset Tracking System such as AssetItem transfers, new assets, archiving old assets when a user is no longer assigned to it etc. I will not include this here because it is quite lengthy.
You could have some classes like this:
Public ID As Integer
Public Class ComputerAsset
Public HDD As Integer
Public CPU As Single
Public Class PrinterAsset
Public Type As String
Public Class AssetManipulator
Public Assets As New List(Of Asset)
End Class and use them like this:
Dim a As New AssetManipulator
Dim c1 As New ComputerAsset
Dim c2 As New ComputerAsset
Dim p1 As New PrinterAsset
Debug.WriteLine("Asset Count " & a.Assets.Count)
Dim item As Asset
For Each item In a.Assets
Note that this may not be the ideal solution for you, but gives you an idea. There are lots of different types of collection objects you could use. Alternatively, you could do some databinding to controls and the database through DataSet objects, etc.
Thanks for the example classes.
I am just trying to link everything together. I can see why the PrinterAsset and ComputerAsset classes are required as they represent an individual object together with the properties that make up that object. As you are inheriting from the Asset class, you just using the AssetID in those classes so that the ID field does not have to be repeated for each class.
What is the purpose of the AssetManipulator class?
How will all this link up with my SQL Express db when it comes to saving the data, editing and deleting.
These are my processes for my IT Asset Tracking project in relation to adding a new asset
Add a new Asset
Select AssetCategory such as Computer, Printer etc and AssetType such as PC, Notebook, Laser Printer
Generate a unique AssetID
Enter or select the relevant asset properties such as OS, HDD, Serial Number etc
Select an AssetItem to link with the main asset such as a monitor, printer etc. The user will see a list of products, select the product, enter the warranty information, serial number etc, click on OK button and the details will be added to a datagrid and then lastly save the whole record.
As I am new to OOP, I am just trying to work out where to begin after creating the user interfaces since I am a beginner as this will give me a good grounding when it comes to developing other projects in the future. It is ok to document the processes that will take place within the application but when it comes to actually coding, this is where I get stuck.
I notice that you have a couple of things going: the Database questions and this one. It is possible that both these methods will not 'align' properly for your application (e.g. you build your relationships between assets in your database/datasets, then it may not be necessary have these objects). Having said all that:
The 'AssetManipulator' is a single object which contains a list of all assets. It could be extended with methods that can add and remove assets (overriding the default list methods), or, basically, 'manipulate' them in some way. Perhaps bringing back a sublist of assets (this is where the database structure is probably more appropriate, since queries can be performed on a set of data).
Tying the objects and the database together may be tricky. I think your best bet (for your application) may be to have all your asset relationships in the database, and just use the VB front end to update/add/view the assets if that's all you are doing.
I guess then I do not need to use objects. I have already begun to create relationships between the tables in the db and I will be performing updates, add, view, delete etc. I will be including Purchase Orders, Contracts, Reports and an Admin function.
Thanks for your response to this as I was getting confused as to what approach to take but this seems to now answer my question.
I would second the idea of not using custom classes.
What you probably need is a Strongly Typed DataSet. Putting the relationships in the database will only be useful if you want to do joined lookup queries. Relationships defined in the database won't really help in the application itself.
You'll need to add a new DataSet to the project, and modify it in the DataSet designer. Add tables that match the schema of your database and then define the relationships between the tables in the DataSet.
Once you've got a well designed DataSet you can take advantage of all the nice databinding features in Visual Studio.
What you are saying is that instead of creating the relationships between the tables within the SQL Express database, create a new Dataset in VB 2005 and then add all the tables and create the primary to foreign key relationships right?
My application will have a summary list of assets in a datagrid filtered down by AssetCategory and AssetType.
Is the Dataset approach still the way to go or will I need to create the relationships in the db.
The DataSet still sounds like the way to go. Whether or not you also define the relationships in the database depends on whether or not you'll use queries that use those relationships.
If you only want to load subsets of database records at certain times (as opposed to loading the entire database) and the query to do so relies on relational parameters, than you'll need the relationships defined in the database as well as in the DataSet.