Designing objects.....

[welshboy202010]

Hi folks,

Having being used to programming in Java for such a long time, I decidede to have a crack at C#.

I'm currently doing a small project for my father's business, and I have a rough idea of what I want it to do.

The problem is I'm having a great deal of hassle designing it, as the program will connect to a data base, and keep track of what's in the van at any given time.

Now I know I'm meant to design the objects first, but to me, it seems like all I'm doing is creating a database and bolting a front end on it. It seems so simple.

What I'm asking is this...

I'm thinking of creating classes, like Part for example, which will hold the details of each part in the van, and then store a part in an array, and then buffer it on to the data base.

Is this a good idea or is it a stupid idea?

Many thanks.

 

[cpjust]

Without knowing more details about what and how the program will be used, it's hard to give you a better answer; but it sounds like a good idea so far.

Other than just storing parts in a database, what will the program do with the data? View, Edit, Add, Delete, Sort...?
Do all the parts have similar attributes (probably stored in the same table), or completely different from each other (different tables for different types of parts)?
Creating some generic interfaces for groups of parts might make like easier in the long run, especially if more features will be added later...

 

[welshboy202010]

Thanks for the reply.

The program will basically manage stock, so stock will need to be booked in and out, keep track of customers and suppliers, and produce job lists for my dad, invoices and quotes for the customers.

I tried to prototype it in Access, (still doing so) but it made my brain go to mush.

I've been toying with using XML to store the data, as it will make the program more portable to an extent.

So you can see my problem, in terms of adding a part object to a data base, or a job object, I have an idea of how I want it to work, but I haven't got the first clue as to where to start in terms of design.

 

[cpjust]

The first thing I'd do is check if there is a free (or relatively cheap) program already available that does what you need. Chances are, somebody, somewhere on the Internet has already created a program like yours and may have some extra features that you didn't even know you needed or thought about. If you can just download and install a program, it would save you weeks of coding and debugging -- time that you could spend doing other things that are on your To Do list...

If you still feel like writing the program yourself, then I think the first thing to do is figure out exactly what information you want to track in the database (Manufacturer, Product Name, Sale Price, Cost Price, Number in Inventory...) Figure out how many different tables you'll need in the database (I'd avoid storing the data in XML format since it's rather large and just adds more overhead than you need). You could store it in an Access database file (or a more sophisticated SQL database if you've got one) and use ODBC to read & write to the database from your program.

Each object should probably represent a record in one of the databases; maybe all deriving from common interfaces so you can be more flexible with how you move your data around.

          ICustomer --> CustomerRecord
IRecord <
          IProduct  --> ProductRecord

 

[dragonwell]

Also keep in mind that there are quite a few different code-generation and object/relational mapping frameworks out there for .NET that make stuff like this pretty easy. For example, there are at least half a dozen free code generators that look at your database schema and generate all the required code to get records in and out of the database so all you basically have to do is create the database and build the forms/navigation/ui part of the program.

 

[welshboy202010]

Many thanks guys,

If you like, I'll keep you posted on how I get on.

 

[trickster321]

Designing objects first is not usually the best approach. I've always found that if you design the underlying data model first then the objects (business entities in microsoft speak) generally drop out from there. You can use ORM (object relational mapping) techniques to map your underlying data model to your business tier objects and there are many tools to do this automatically but beware of bloat code. It all depends upon the complexity of your data model and how it relates to your business objects as to whether tools of this nature would be useful.

I personally use n-tier development practices in that I have a seperate data access layer, business logic tier and UI. Seperation like this means that you can vary the way you communicate with the db without effecting your business logic. You mention XML and that is a possible way to go for the data access layer. There will be an overhead in serialising your objects to XML but the advantage is that you could evolve the data access layer into a web service and so make the business tier database independant (you may need to create a thin web service client that sits on top of the database depending upon the database you are using and its in built web service support).

Rick Edwards

 

[stevexff]

Sorry, but I have to disagree with trickster321, although it's possible that we aren't interpreting the term 'data model' in the same way. (He's right on about separating the layers, though). In my experience, if you do the data model first, you end up with the 'tail wagging the dog'. As databases are typically much harder to refactor than code, you end up jumping through hoops in the code to make up for the shortfalls in the data model. How many times are developers faced with the task of enhancing systems where the existing data model doesn't quite cater for the new requirements? Don't paint yourself into a corner before you start.

Start with a list of requirements, and maybe some use cases. It's easy to come up with new cool functions that you are sure you could easily implement while you are designing it. Resist the temptation!

I normally identify the business objects first. These are the 'nouns' in your model of the real world. So Van, Part, Customer, Order, Warehouse, might be good starting points. We might decide to generalise Warehouse and Van into Location, as we really only want to know where the parts are at any point in time. Are the Parts something that needs to be tracked individually (typically something with a serial number, like a PC or a car), or just a quantity of some stock item like 2 boxes of 1" #8 woodscrews? Use this to determine the attributes of the objects.

Think about things that you need to do to those objects (the verbs), and which object has the responsibility for that action. These become your methods.

When you've done a few iterations of this, walked through your use cases, and you are happy that the objects you have meet your requirements, start worrying about how you are going to persist them. Your methods will give you a clue as to what CRUD functionality is needed, and where.

Probably a bad idea to write your own persistence code, unless you have some really unusual requirements. Use one of the object-relational mapping tools (NHibernate is supposed to be good for .NET), and set up your tables accordingly.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[trickster321]

Hmmm, ok then we agree to disagree.

If you are working on a ground up design of a system then there is no reason why the underlying database design cannot cater for future flexibility and extension. I would suggest that if you have had to jump through hoops in the past to get your business objects to play nicely with the database then the design of the data model was poor to begin with.

Data is usually the foundation of software development. We write code to manipulate it, display it, send it to other places and so on. Hence, get the foundations right and you can build on them. To be frank your data model generally mirrors your business entity objects (or vice versa depending upon your view point), so if you get one right the other should follow. I start with the data model (or structure if you will), to me it makes more sense as my business entity objects relate directly to it. I then build up my business tier to manipulate these entity objects in the way I wish using stateless management classes. This way ensures that I get the relationships between data correct from the outset and I can easily extend and cater for change both at the data level and in the business tier.

The key is look at your base objects in terms of the data they represent. The relationships built up in your relational database go a long way to defining your object relationships. And the data they represent leads more intuitively to the responsibilities of the objects you create (IMO).

And remember the mantra...

"Premature optimisation is the root of all evil"



Regards

Rick Edwards

 

[stevexff]

Rick

If you are fortunate enough to be working on a clean slate, then I'd probably agree with you. But the majority of projects don't have this luxury, hence my comments about jumping through hoops.

From an object-oriented perspective, the database is merely somewhere to keep the objects when the power is switched off (cue army of DBAs rushing to red flag my post). It could just as easily be an XML structure or a flat file if you don't need the full RDBMS functionality.

There is a disjoint between the object-oriented world and the relational model. Start with your objects, and worry about how you are going to store them afterwards.

For a comedy take on our difference of opinion, see

http://www.waterfall2006.com/ambler2.html

(the rest of the site is even funnier, and a brilliant spoof)

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[AlexCuse]

steve - I am not a DBA, and will not red flag your post (and I was actually ready to post this before you made this most recent post, but when I refreshed decided I should add a disclaimer). But I did have to add this:

In most business environments, databases are asked to support more than one application at a time. Because of this, to design a database around one particular application is just plain silly. In fact, it could be because someone designed their database in this fashion in the past that you have had to jump through hoops to accomodate a poorly built database. A well built database should be able to work with any application that needs to connect with it just fine, but if it is tailored to just one application this is done at the expense of all other applications that need it. I would hardly call this sound design.

By the way, that website was good for a chuckle. But everyone knows you should only go to the 59th normal form

Ignorance of certain subjects is a great part of wisdom

 

[stevexff]

AlexCuse

You are right of course, and in the real world we hardly ever get to make a nice, simple, stand-alone application (the stereotypical bookstore application springs to mind, for some reason). We just have to work with what is there already. However, if you are creating a new application from scratch, you don't have any other applications to consider in your design.

But if your business objects are well designed, they should be re-usable across other applications, as and when they get developed. The encapsulated business rules ensure that all parts of the business follow the same process to accomplish the same taks, and this can protect your database from abuse.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[AlexCuse]

I suppose the key is just to have a good database, and good application. Then you have no worries

If there is a problem in any layer, then its' going to make the other two look bad. I think the business rules are probably most important (just don't tell the other database guys ;-) )

Ignorance of certain subjects is a great part of wisdom

 

[BobRodes]

<

http://www.waterfall2006.com/ambler2.html

I sent this to my boss (I was working in a RAD department at the time) last year, and asked if I could go. Unfortunately, he thought I was serious. So beware! LOL

 

[BobRodes]

I generally find myself resolving this issue in terms of yin and yang. See, the data is the yin, or state of being, and the business objects are the yang, or state of doing. Yang acts upon yin, yin informs yang with the results of action, and the process repeats (and simultaneously happens all at one time) in the oneness of the tao. This is a practical application of the principle that all conflicts are resolved in the tao, such resolution finding its application in harmonious software development.

HTH

Bob

 

[trickster321]

Cosmic jam there Bob!

Actually if we're talking about interoperability then this is where I put my Web Service hat on (for I work in the internet space) and could argue that in fact all your business logic should do at the DAL is create XML, period. It's then up to the consuming data store to react to the incoming XML in the way it sees fit.

To be frank, I'm not arguing that all good software starts from the data, but from a new application perspective its certainly a good place to start. Unfortunately this doesn't help the poor schmucks that have to deal with some hacked up nastiness of a database in which case all that are left are objects.

I like the yin/yang approach, sums up the design process quite nicely

Rick "off to meditate on what he has learnt" Edwards