IT Asset Tracking System Objects


  • 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.

    Thursday, June 15, 2006 11:08 AM

All replies

  • 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.


    Thursday, June 15, 2006 12:32 PM
  • 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.


    Thursday, June 15, 2006 2:13 PM
  • You could have some classes like this:

    Public Class Asset
    Public ID As Integer

    Class ComputerAsset
    Inherits Asset
    Public HDD As Integer
    Public CPU As Single

    Class PrinterAsset
    Inherits Asset
    Public Type As String

    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.


    Monday, June 19, 2006 12:38 PM
  • 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.




    Wednesday, June 28, 2006 12:30 PM
  • 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.

    Wednesday, June 28, 2006 1:17 PM
  • 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.

    Wednesday, June 28, 2006 2:05 PM
  • 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.

    Wednesday, June 28, 2006 2:45 PM
  • 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.

    Wednesday, June 28, 2006 3:22 PM
  • 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.

    Wednesday, June 28, 2006 3:38 PM
  • I will be using queries when it comes to filtering down records within the application front end such as the summary screen as well as for reporting purposes.
    Wednesday, June 28, 2006 3:44 PM