OO class design question (logic placement)...

  • Thread starter Thread starter Brad Pears
  • Start date Start date
Daniel,

A shared class is nothing more than another name for the classic module, it
can be OO but certainly not OOP.

Cor
 
Brad,

If you really want to use classic Unix methods instead of Net methods
(AdoNet and all its benefits), than at least make 3 layers, a DataLayer than
handles your DataBase, a Business layer than handles your class and all the
rules about, and UI layer than communicates with the User. DataLayer <>
Business Layer <> UI layer. Never let the UI communicate with the DataLayer,
although sometimes you have the idea that it is better.

Happy coding, I assume you do this for hobby, because for business, this
takes in my idea a lot more time than the general dotNet methods.

Cor
 
Thanks for you help...

No I am doing this for business. I have programmed in many different
languages over the years but this is my FIRST experience in OO design and
also my FIRST experience with VB.NET and SQL server. Previous to this I was
using Access 2000 and an Access DB and using some OO techniques but NEVER
did I ever design a classes etc.. etc...

Prior to that it was DbaseIV, Clipper, COBOL and PL1. So you can see I come
from way back!! This is really new to me and a lot of the way we used to do
things and think have to be thrown out or used sparingly when it comes to
the .NET framework and OO principals!! Very hard for an old dog like myself
to pick it all up and turn out a well designed and written application!!

Brad
 
Ok, I took a quick peek at your comments in that article and I have a couple
questions...

In the application I am working on I have many tables. Basically what I was
thinking was that I would have a "Contract" business class (this particular
application is meant to allow the sales people at our organization create a
home "contract" with a client.) and then I have a "Contract Management"
class called "Contract_Data" which is what does all of the actual calling of
stored procedures to do the data selecting, nserts, updates and deletes
from various tables. So really I am wrapping this "management" class in the
"Contract" business class - as I am calling the management class methods
from the business class... Hope that makes sense....

There are a couple of things I am having issues with though... One of my
tables - the main contract table has quite a few fields in it. So, when I
want to save a contract in the database I find I am passing many fields from
the business class to the data class method that performs the "database
save" and in turn these fields are then passed as parameters to the stored
procedure to do the actual insert/update etc...

Now, I think that what I am doing is correct but is this typically how this
type of thing works?? What I am finding is that when the "Save" button is
clicked on the form, I am setting all of the "Contract" business class
properties (that has been instantiated) to the values of the forms textbox
control values etc.. etc.. (of which there are many) and then I am then
passing all of the contract class properties I just set over to the data
class to do the update...

Is there an easier way I shoud be doing this or is this typical of how this
type of thing works?

Thanks, Brad
 
So using your example there, I could use this in code like this...

if classname.exists then
do something
else
do something else
endif

What type of code needs to be placed in the "exists" method of the class in
order to be able to return a true or false?

Thanks, Brad
 
Brad Pears said:
That was very well written. I had never thought of having a property
'State' that is set for the object but I think it makes sense...

Basically what I have happeneing now is that the "Save" method on the
business class "contract" object calls an "update" method on the contract
"data class" object. ( I split the object so that I have a business object
"contract" and a data object "contract_data"). This update method in turn
runs a stored procedure to do the job. The stored procedure itself
determines whether or not to "update" the data or "insert" the data. There
is a completely separate method to "delete" a contract which in turn runs
a stored procedure to specifically do just that...
Click to expand...

I like to separate all three functions of add, update or delete, whether
that be with a stored procedure or with dynamic SQL statements in code.
So implementing a state property really doesn't buy me anything in this
instance BUT I do like the idea of having a state on every object and I
think it makes sense. Is this a common thing to have?? I have not seen a
lot of this in reading OO material or viewing OO design techniques/coding
techniques...
Click to expand...

The state property, which can also be implemented at the business level as
well allows one to know the state of the object when dealing with the object
at the UI, Business or Data Access level.

I always at any level of the logical tiers of UI, Business and DALC I want
to know the object's state. Object what is your state so that I can take the
correct processing path.

Take for instance the case where you have a Business Object Collection a
collection that's holding multiple business objects, and during the
BOC.Save, it starts walking the collection invoking each object's
object.save, then I may need to know the state of the object. Maybe, I need
to populate an object with a parent key from a parent object or other things
like that, before I save the object.

What's the state of the Business Object Collection is the BOC DIRTY, because
a object within the BOC has been marked DIRTY so it's DIRTY too? Why should
I invoke the BOC.Save and start walking the collection when no object is
DIRTY within the BOC, because the user pushed the Save button?

There is another state of an object called IsValid. The object is asked to
validate itself. If the object is not valid, the why should I invoke the
Object.save? If all objects are not valid within the BOC if its IsValid is
false, then why should I invoke the BCO.Save.

Where I leaned all of this in using VB 6 for those solutions back in the
day, VB.NET and C#.NET, which I have been using these OOps concepts, since
year 2000, from Web, Windows desktop, Console and NT Service applications
for .NET is CSLA.

http://www.lhotka.net/Article.aspx?id=1351540e-b941-446a-bacb-e0059cc82ee7

If you like, you can get the book, read the book, understand what's in the
book, download the framework put it together, download the project put it
together to use the framework and then you'll understand OO programming
techniques.

Keep in mind now, it's not about trying to implement a framework, which most
companies do use some kind of framework, in house written as an example.
It's about understanding the concepts, who are the players and how are the
players being used.

And then saying to yourself, I can use these concepts, I can make my own
objects, I don't need the CSLA framework, and I can run with this myself.
 
Thanks for you help...

No I am doing this for business. I have programmed in many different
languages over the years but this is my FIRST experience in OO design
and also my FIRST experience with VB.NET and SQL server. Previous to
this I was using Access 2000 and an Access DB and using some OO
techniques but NEVER did I ever design a classes etc.. etc...

Prior to that it was DbaseIV, Clipper, COBOL and PL1. So you can see I
come from way back!! This is really new to me and a lot of the way we
used to do things and think have to be thrown out or used sparingly
when it comes to the .NET framework and OO principals!! Very hard for
an old dog like myself to pick it all up and turn out a well designed
and written application!!
Click to expand...

It seems you're a bit in over your head? Have you considered using a
prebuilt data access layer framework? CodeSmith is a template generator for
..NET - it lets you build customized DALs very quickly. CodeSmith has
several free templates. Otherwise as I posted early, I'm a great purponent
of LLBLGen Pro. LLBLGen Pro is a very complete and solid DAL framework. You
could start with these frameworks and save yourself the trouble of
implementing everything from scratch. While implementing everything from
scatch maybe a good learning experience ... it may not be worth the time or
effort (lots of things to consider including recursive fetching of
entities, security, etc. etc).

You might want to do a google search for ORM (Object Relational Mapping).
which in essence is what you're trying to do - mapping the database tables
to objects. Paul Wilson has a relatively cheap ORM tool which you may want
to look at as well.


http://www.ormapper.net/

http://www.codesmithtools.com/

http://www.llblgen.com
 
Brad,

Why are you so fixed on OO and not on OOP, I would look first to the later,
in Net are so much classes with build in OO that it will save you a lot of
time to focus your eyes on the later. Building all the classes from scratch
is in my eyes ridicilous.

As I wrote before, the complete OOP dataset and other ADONET features are
build on the relational model from SQL based database servers (they all have
the same model), however there is nothing better than those at the moment
than those servers..

Do you want to go the classic OO way, than you have in my idea first to take
a look at Linq.

Cor
 
Spam Catcher said:
It seems you're a bit in over your head? Have you considered using a
prebuilt data access layer framework? CodeSmith is a template generator
for
.NET - it lets you build customized DALs very quickly. CodeSmith has
several free templates. Otherwise as I posted early, I'm a great purponent
of LLBLGen Pro. LLBLGen Pro is a very complete and solid DAL framework.
Click to expand...
You
could start with these frameworks and save yourself the trouble of
implementing everything from scratch. While implementing everything from
scatch maybe a good learning experience ... it may not be worth the time
or
effort (lots of things to consider including recursive fetching of
entities, security, etc. etc).
Click to expand...

IMHO, one needs to learn from scratch and understand the principles of OO
design, concepts and programming, which most programmers, particularly those
that use framework tools fail to understand. There is nothing wrong with the
tools, as I have used them myself like NHibernate. But I have seen
programmers use a framework tool out the gate and still didn't understand OO
design, programming and concepts.

Two books the OP may want to consider are Domain-Driven Design. I just
happen to use the C# one since I know C#.

http://domaindrivendesign.org/books/index.html

Although, this book Head First Design Patterns examples are in Java, which
is not hard to read and understand, OO programming is OO programming, and
the principles and concepts of OO design and programming can be directly
applied to .Net solutions, since Java was there first.

http://preview.tinyurl.com/2h6m56

One may be in a situation where a framework tool has not or won't be
implemented.

Or the framework tool and the code it produces doesn't provide optimal
execution, such as speed, and one has to take over and do it them self.

For me, those two books, along with the CSLA books, brought the concepts of
OO design and programming home for me.
 
Ok, I think I am missing something really big. OO = Object Oriented,
OOP=???? Isn't it Object Oriented Principals or Programming?? What is the
difference between OO and OOP?? I gues I don;t know what OOP really stands
for if OO and OOP are different...

Thanks, Brad
 
Brad Pears said:
Ok, I think I am missing something really big. OO = Object Oriented,
OOP=???? Isn't it Object Oriented Principals or Programming?? What
is the difference between OO and OOP?? I gues I don;t know what OOP
really stands for if OO and OOP are different...
Click to expand...


An academic question. I did OOP in VB6. Some say it wasn't OOP because VB6
didn't support inheritance. I say, it was OOP because my "orientation was
programming with objects".


Armin
 
I'm afraid I cannot answer this original question. I have always heard these
2 terms as interchangable and have never heard anything which suggests otherwise.

I would be interested to hear what others have to say on the subject.
An academic question.
Click to expand...
I did OOP in VB6. Some say it wasn't OOP because
VB6 didn't support inheritance.
I say, it was OOP because my
"orientation was programming with objects".
Click to expand...

I also worked with Vb6 and 5 and 3 before that.

It is *generally* accepted that VB6 is not Object-Oriented but Object-based.

Within programming things are labelled by the community at large and in this
case Armin you may choose to call VB6 Object-oriented but the term has more
than a literal meaning it is a specific labell that categorises languages
that support "Inheritence", "Encapsulation" and "Polymorphism".

Vb6 supports only "Interface Inheritance" and not "Implementation Inheritance"
and therefore most professional programmers will discount it from the object-oriented
label

This is likely to start a big religious debate so I suggest that the OP perform
some searches of his own to prove this to himself.

All of the quoted terms should be understood and supported by a language
that tries to make this claim
 
Brad,

OOP is not only working with OO (data) classes. The whole concept is based
on Objects which are initiated from a class. Every time you create a new
object and use that, until it goes out of scope or any other reason it is
not necessary anymore, than you destroy it. However, the last is not
necessary in managed code anymore because that is exactly what is managed
for you.

Just a very short way of trying to tell what is my (and not only my) idea
about OOP.

In other words, your program is build with objects which are instanced from
classes and not with modules as in the classic VB way. (In Net modules have
as well the name shared or static classes. In fact they are consequently in
memory as a VB module normally was too. (When they were not separated in
extra DLL's or whatever).

Cor
 
Actually, I believe MS even referred to VB 6 as "Object Based" and not
"Object Oriented" for this very reason that it didn't support inheritance
and polymorphism.

Mike.
 
Thanks everyone...

Yes, well you pretty much backed me up on what I thought it was... Basically
I had the feeling that is pretty much about the inheritance, polymorphism,
encapsulation etc...

Yes, I never have ever heard that VB6 was an "object oriented" language -
although possible to do some OO stuff there - just not enough to call it a
full fledged OO language... My sister in law was a Java developer for IBM
(was pretty high up too) and she pretty much poo-pooed any language that
called itself OO - even .NET products. (I think the only other one she had
used that she liked was VisualAge Smalltalk) But Java people seem to be
very dedicated to that product and don't really see (or care) what other
products can actually do... (I've known a few of them)

Thanks for helping clarify - I thought I was missing something!

Brad
 
Back
Top