dcsimg
December 5, 2016
Hot Topics:

Beginning Objects in VB - Part 3

  • November 19, 2002
  • By Sam Huggill
  • Send Email »
  • More Articles »

OK. So here we are. Ready to start out first project with an object model. I suppose you've got VB open already and are scanning through the page looking for the first signs of code. Well, here comes the surprise - before we do any coding whatsoever we are going to spend quite a bit of time PLANNING our object model.

Yes, the hated word planning that every amateur programmer runs away from - I can tell you from raw experience planning really does help. When I first started programming, I was diving head first into projects trying to get as much coding done as I could before I got fed up with the project.

This application had a great deal of promise, and in fact works reasonably well at the moment (despite the number of bugs I keep hearing about!) Anyway, I ran off with that and went straight into coding. Now the project has died somewhat, and I've no chance of reviving the project unless I take on rewriting the whole thing.

Anyway, getting to the point (at last!) - planning really does pay off. However much you may be good at designing on the fly; such as building your objects and defining the main entities in your program there will always be things that you come across that you hadn't thought about. Going through before hand and writing down what you're going to do will help you see these things more clearly.

So, as I finally get onto the whole point of this part, the planning of our customer database model. Firstly, we're going to have a variety of objects. Think about a customer; that's one to start off with. A customer is an entity in itself, and therefore we should have an object to deal with that entity.

Secondly, lets think about the ways in which a customer will relate with other entities. Well a customer is going to have a contact within your company that will allow it to negotiate and communicate with your company. So we should create a Contact object to deal with that link.

No doubt there are other ways in which these entities interact with others, but for now, we are going to simply use that structure to begin our example.

Now that we've defined the main entities, lets look at what properties each one is going to have.

Customer Object:
Name - Obviously each customer is going to have a name.

Here are several more obvious ones:

Address
Phone Number
Fax Number
Web Site
Email Address

Now, we need to link a customer to a contact in our company. Thinking about it, we're only likely to have one customer connected to one contact, but our contact may handle several different customers. In database terms, we would say that the customers have a 'many to one' relationship with a contact.

Simply put, this means that we will have several customers related to one contact.

Due to this, the customer object will need to have an individual id to allow us to distinguish between customers. This also means that our contact will need an id to link the two together, but we'll get to that when we move onto the contact object.

So now we've got a new property, a customer id. If we think about a database, this will simply be a field that increments when a new record is added, ensuring that it is a unique number.

Here's a quick list of the properties under the customer object:

Customer Object:
ID
Name
Address
Phone Number
Fax Number
Web Site
Email Address

You'll notice that Ive put the id at the top. This is customary when dealing with a database table, as you will see in future parts when we build this application.

From what I discussed before, we need a way to link a customer to a contact. This can simply be achieved by adding a contactid field in which we store the id of the contact that allows us to link a customer to a contact without typing out all of the contact's details several times over. I'll talk more about this in a bit.

Now, onto the contact object. Here are the obvious ones first:

Contact Object:
Name
Address
Phone Number
Email Address

Our contact will also need an id, so we'll add that as well. I bet you're wondering why the contact's address is there? The customer isn't going to want it (unless they completely screw up the project!) so why is it in the list? Well, simply because your company will need to keep this kind of information about someone in your company, and rather than have the same data kept in two places, we might as well keep it with the other information. This procedure is known as 'normalisation' in that we prevent data from being duplicated across a database.

As I said before, we don't really want the customer to know their contact's address, so we'll have to keep that in mind as a business rule when we come to writing code.

That's about it really. So here's the final list:

Contact Object:
ID
Name
Address
Phone Number
Email Address

So, we're now ready with our model! Unfortunately, you're going to have to wait for the next part of this series to find out about our objects, databases, business rules and more complicated bits and bobs!

Until then, let me know how I'm doing by clicking the Post Feedback Now link at the bottom of any of the pages in this article.

Until next time - keep hacking!





Page 4 of 4



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel