Object Oriented Basics

I found some good articles, but nothing to pull everything together for me. To keep this simple, lets create a class to simply print "hello world" to a label on my page. My questions are:

1) I want to put the class code into an external file that I can reference and use on multiple pages. What do I need to do?

2) How can I have the class generate a string that is displayed on a label since I cant just say labelID.text=string?

thanks

You can do something like.

1public class DisplayString2{3public static void DispString(Label lbl,string str)4 {5 lbl.Text = str;6 }7}89// this is your call to that method from somewhere else.1011DisplayString.DispSpring(this.labelID,"Hello World");

Last time i tried that it worked.

narowgate:

I found some good articles, but nothing to pull everything together for me. To keep this simple, lets create a class to simply print "hello world" to a label on my page. My questions are:

1) I want to put the class code into an external file that I can reference and use on multiple pages. What do I need to do?

Hi,

That's called business object. Follow these steps:

1. Create .cs/.vb file where you should do something you want.

2. Compile the business object into a usable object. Then you will get *.dll in your project's bin\debug folder.

3. Add your new DLL via "Add Reference" when right click the Solution Explorer.

4. Finish. You can do your job.

narowgate:

2) How can I have the class generate a string that is displayed on a label since I cant just say labelID.text=string?

thanks

The reply above is right direction for you to follow. I hope that you should write your class with return a string or add get method. Then you can use get method to get string in the code-behind file.

Happy programming.

Object Oriented Analysis and Design (OOAD)

Hi,
If you have learn about OOAD, you should know about class diagram. In UML, class diagram is devided among

Boundary Class; which responsible to User InterfaceEntity Class, which hold data about an object (for example Car.cs)Control Class, which responsible for coordination, interaction

I learn OOAD and try to build a simple web article managementapplication using C# (ASP.net). I have create a class diagram for thisapp, but confuse how to implement it on ASP.net. I have upload part ofmy UML in
http://www.topcupid.com/UML.zip
I had try to search on MSDN Library but only find an explanation aboutMCV (Model-Control-View). In MVC, Model is like an entity class (forexamle car class), View is the ASPX page, Control is ASPX code behind.
MVC is like boundary, entity, control class in UML, but things that make me confuse is :
1. Boundary is a class in UML, but in MVC, the view is the aspx page which is not a class
2. If I make code behind in ASPX page as a boundary class, then who is the control class?
Please help me

Thanks, any answer will be appreciated.
Yonscun

Here is what a member of the ASP.NET Teamtold me about MVC in ASP.NET:

First, let me point out that MVC has never been a pattern that fit well in ASP.NET. Actually, Martin Fowler introduced in "Patterns of enterprise application architecture" the Page Controller pattern that better reflects a typical ASP.NET application. There are some MVC frameworks for .NET, but they are somewhat convoluted and sacrifice most of the cool things of ASP.NET on the MVC altar.

However, if you are truly keen to use the MVC pattern with ASP.NET, the following article will help you:
Applying Robustness Analysis on the Model-View-Controller (MVC) Architecture in ASP.NET Framework, using UML

If you want to use theconcept of MVC, without the true pattern, you can do the following (which many developers do): consider your .aspx page to be theview, consider its code-behind to be thecontroller, and allow a business object (or even just a DataSet) be themodel. This wouldnot be the MVC pattern, but it will give you a way of separating concerns, and a way that fits well with ASP.NET.

By the way, an .aspx pageis a class, it is simply authored in a different way (it uses declarative programming rather than procedural programming).

I was preparing for the IBM OOAD exam in 2001 when I got the email to start C# training from Microsoft. And last year we used a lot of MVC reference materials from MSDN and Microsoft is expanding the patterns but to enable developers in a web application context not the complete UML. Try the links below for a lot of UML resources including complete
factory pattern with class diagram and C# code all from OO experts. Hope this helps.

http://openmymind.net/NetDesignArticles.aspx

http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/CustEntCls.asp

Hi thank for replying,
Actually Model-View-Control is not my primary goal.
I just try to figure out how to implement boundary classes, entityclasses, and control classes. After googling and searching in MSDNlibrary, I found about this MVC concept.
But any body know how to implement this boundary, control, and entity class in ASP.net?

You are a student so try these links everything you need to study is covered. Hope this helps.

http://consulting.dthomas.co.uk/software_architecture_consulting/articles_resources.htm

http://msdn.microsoft.com/architecture/community/webcasts/default.aspx

Hi, thanks to all (a really helpful link)

Eh, I confuse about "broker class" that said can separate business (entity) class with database connection.

If "car" class has a broker class named "CarBroker" class then please can anyone tell me how this class work?

Edit

The Broker is middletier like message queues or Microsoft Biztalk, the later is very expensive but it can talk to all systems through XML. Again you are a student so I have got you study links but try and get UML distilled by Martin Fowler so you can get the short version of all you need. Asp.net stripes all these to bare bone because HTTP is stateless, human interaction application needs are different from business oriented UML. There is a problem with the second link the *** replaced (d1ck ) which is Richard in short but not accepted word on the forums. Hope this helps.

http://www.jot.fm/issues/issue_2004_09/article1
http://www.csci.csusb.edu/***/samples/uml.html

Hi thanks everyone, your links really help me a lot

I read some of tutorial link abouve and read again my OOAD books (simmon bennet - MC Graw Hill), now It's a little clear how this broker work.
But I still confuse in better way to store my newly created class to MSSQL database.
Lets say an administrator want to post a new article to his website so all visitor can read it.
The admin surely will create a new instance of class article and store it on database.
It's pretty simple to create an instance of article class. But when an instance of article class is created, it must to immediately stored to database.
But Who will responsible to store article to database? The article class itselft or it's database broker class?
If article class is responsible to implement saveToDatabase() function then separation between article (entity class) and article broker class (database broker class) will be broken.
If broker class is responsible to implement saveToDatabase() function then how an instance of article class send itselft to database broker? or maybe article class just need send all its attibute?
Please help me,

Try this it covers Objects and Data including O/R(Object relational ) Mapping but I think you should post on the Architecture forum to get the right answer. Hope this helps.
http://martinfowler.com/eaaCatalog/

object oriented design

I am fairly new to oo design and I am looking at developing an object
oriented asp.net application which will be built on top of a relational
database. I have read quite a bit of the theory but find it hard to put it
into practice. In particular I am in terms of interacting with the
database. It seems to me classes map quite closely to database tables and I
end up with a bunch of methods in each class which simply call stored
procedures to do data access eg. AddOrder method in an Order class. In that
case oo design just seems like a wrapper on top of the database. I don't se
e
what is gained over just using procedural techniques to group related
functions together into modules. I am sure I am missing something.
Any pointers to get on the right track? Specific advice or samples of a
good design would be more appreciated that a pointer to a general book
(although if someone knows of something dealing with this specific problem
that would be great.)
--
ScottScott,
I don't think you are missing anything. For simple systems your database
does map very closely to your objects and you do end up with a lot of code.
Some solutions to this are to use (a) a code generation tool (google search
CodeSmith) and (b) a professional O/R mapper (google search WilsonOR)
I love codesmith :)
Anyways, back to the topic..the benefit you gain with OO is more noticable
as your system grows complex. You'll see that your relational data doesn't
map so well to your object world (google search Object-Relational impedence
mismatch). A classic example is inheritance which brings forth tremendous
benefits that you can't get from a more procedural technique.
A solution might be to use a Data Mapper Design pattern
(http://www.martinfowler.com/eaaCatalog/dataMapper.html). This would leave
your classes as more pure domain objects and move the mundane and repetivie
mapping to its own layer/class. Great for even more flexibility.
If you aren't taking advantage of encapsulation, abstraction, inheritance
and polymorphism in your classes, ask yourself if you could..or think ahead
and see if they might be necessary with future requirements. Chances ar the
flexibility you've given yourself by this approach will pay off for itself
...even if it seems a little straightforward now..
Karl
MY ASP.Net tutorials
http://www.openmymind.net/
"scottrm" <scottrm@.newsgroup.nospam> wrote in message
news:4A0BD364-9A7A-44E1-82DC-BFD4260F14D5@.microsoft.com...
> I am fairly new to oo design and I am looking at developing an object
> oriented asp.net application which will be built on top of a relational
> database. I have read quite a bit of the theory but find it hard to put it
> into practice. In particular I am in terms of interacting with
the
> database. It seems to me classes map quite closely to database tables and
I
> end up with a bunch of methods in each class which simply call stored
> procedures to do data access eg. AddOrder method in an Order class. In
that
> case oo design just seems like a wrapper on top of the database. I don't
see
> what is gained over just using procedural techniques to group related
> functions together into modules. I am sure I am missing something.
> Any pointers to get on the right track? Specific advice or samples of a
> good design would be more appreciated that a pointer to a general book
> (although if someone knows of something dealing with this specific problem
> that would be great.)
> --
> Scott
Although it is quite hard to learn initially, Enterprise Core Objects from
Borland is an excellent tool.
You design the model in UML, it generates the DB for you, and you work only
with objects (never the db).
My website howtodothings.com was written with it, and I don't have a single
SQL statement in the whole project.
Pete
====
Read or write articles on just about anything
http://www.HowToDoThings.com
My blog
http://blogs.slcdug.org/petermorris/
Hi Scott,
Well, it sounds like you're on the right track, believe it or not. You have
to look at the evloution of programming to understand it more clearly.
In the beginning (almost), code was simply instructions that were executed
in the order in which they appeared in the source. It was soon discovered,
however, that certain blocks of code were commonly executed again and again.
This was initially solved with GoTo statements, which instructed the
compiler to go to a certain location in the code, execute the instructions
there, and return to the point it left from. And this lasted a while.
As the size and complexity of programs grew, GoTo statements made for some
serious spaghetti code, which became hard to maintain and modify. The
concept of more ordered source code, using functions and sub-procedures was
introduced to make code easier to manage.
Of course, this convenience only lasted awhile, as programs grew more in
complexity, and multi-tasking operating systems were introduced. Believe it
or not, Windows 3.1 was written in C, not C++. It used a heck of a lot of
loops and nested loops to do multi-tasking, messaging, and so on. You can
imagine the difficulty in maintaining such a huge program, which was made up
essentially of a single set of instructions that was immense in size.
At this point, due to the complexity of programs, new data types were
introduced called "structures." A structure is simply a combination of
multiple data and types of data into a single unit. It made code
organization easier, and a structure could hold both State and Process. In
other words, a member of a structure could be a piece of data, such as an
integer, or it could be a process, such as a function. Are we starting to
sound a little familiar at this point? We should be.
Enter Object-Oriented programming. Structures evolved into
objects/types/classes. OOP enhanced the structure concept, and added a few
of its own:
Inheritance: Inheritance performs much the same function as functions and
sub-procedures in terms of what its purpose is. By defining a base class,
and inheriting it, one could build multiple classes that shared some of the
same state and process, but with additional characteristics as well. In
addition, the developer doesn't have to re-write the same code to create a
new class. The code in a class is relatively lean, as much of the code
resides in the base class. This makes code maintenance and debugging much
easier.
Encapsulation: OOP introduced the idea of hiding members of a class in a
variety of ways. By doing so, the possible errors that could occur were
minimized. Only the members necessary to access fro outside the class are
exposed. There is no way that something outside the class can modify
something that it should not. This also enhances code maintenance and
debugging, by reducing the number of variables that can affect performance
of the app.
Polymorphism: Plolymorphism was actually introduced in earlier procedural
languages, with the concept of overloaded functions, by defining a function
as accepting different data types, and behaving differently when using them.
Classes extend the concept with overrides and other similar mechanisms that
allow a class to behave differently in different circumstances.
Abstraction: A little harder to define. Abstraction is an outgrowth of
encapsulation, in a sense. By hiding the details of how an object performs
its tasks, other objects can treat the class as if it were a "machine" that
performs some task, rather than a set of instructions. This also simplifies
code creation and maintenance.
All of this has come about as a result of computer and software evolution.
Just as Assembler language was developed to reduce the amount of time
necessary to write an application in machine code, each evolutionary stage
of programming technology is designed to reduce the amount of time and
resources necessary to write, debug, and maintain software.
The better your object model, the easier and quicker you can write
applications with it. If you're wise, you will create re-usable classes that
will continually reduce the amount of time and effort spent in future
development.
So, in conclusion, what is gained by OOP is the same thing that is gained
with "just using procedural techniques to group related functions together
into modules." It is simply the next stage in the evloution of programming.
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"scottrm" <scottrm@.newsgroup.nospam> wrote in message
news:4A0BD364-9A7A-44E1-82DC-BFD4260F14D5@.microsoft.com...
>I am fairly new to oo design and I am looking at developing an object
> oriented asp.net application which will be built on top of a relational
> database. I have read quite a bit of the theory but find it hard to put it
> into practice. In particular I am in terms of interacting with
> the
> database. It seems to me classes map quite closely to database tables and
> I
> end up with a bunch of methods in each class which simply call stored
> procedures to do data access eg. AddOrder method in an Order class. In
> that
> case oo design just seems like a wrapper on top of the database. I don't
> see
> what is gained over just using procedural techniques to group related
> functions together into modules. I am sure I am missing something.
> Any pointers to get on the right track? Specific advice or samples of a
> good design would be more appreciated that a pointer to a general book
> (although if someone knows of something dealing with this specific problem
> that would be great.)
> --
> Scott
Hi Scott,
On top of what's been said, the fact that your db classes are just
wrappers for the db allows for a very academic N-Tiers architecture.
Down the road, N-Tiers is (are?) safer and less error-prone.
PS : and if you read Kevin's answer, you'll see that oo teaches you to
be both synthetic and crystal-clear. Nice piece, Kevin.
HTH,
Michel
"examnotes" <scottrm@.newsgroup.nospam> wrote in message news:<4A0BD364-9A7A-
44E1-82DC-BFD4260F14D5@.microsoft.com>...
> I am fairly new to oo design and I am looking at developing an object
> oriented asp.net application which will be built on top of a relational
> database. I have read quite a bit of the theory but find it hard to put it
> into practice. In particular I am in terms of interacting with th
e
> database. It seems to me classes map quite closely to database tables and
I
> end up with a bunch of methods in each class which simply call stored
> procedures to do data access eg. AddOrder method in an Order class. In tha
t
> case oo design just seems like a wrapper on top of the database. I don't
see
> what is gained over just using procedural techniques to group related
> functions together into modules. I am sure I am missing something.
> Any pointers to get on the right track? Specific advice or samples of a
> good design would be more appreciated that a pointer to a general book
> (although if someone knows of something dealing with this specific problem
> that would be great.)

object oriented design

I am fairly new to oo design and I am looking at developing an object
oriented asp.net application which will be built on top of a relational
database. I have read quite a bit of the theory but find it hard to put it
into practice. In particular I am confused in terms of interacting with the
database. It seems to me classes map quite closely to database tables and I
end up with a bunch of methods in each class which simply call stored
procedures to do data access eg. AddOrder method in an Order class. In that
case oo design just seems like a wrapper on top of the database. I don't see
what is gained over just using procedural techniques to group related
functions together into modules. I am sure I am missing something.
Any pointers to get on the right track? Specific advice or samples of a
good design would be more appreciated that a pointer to a general book
(although if someone knows of something dealing with this specific problem
that would be great.)
--
ScottScott,
I don't think you are missing anything. For simple systems your database
does map very closely to your objects and you do end up with a lot of code.
Some solutions to this are to use (a) a code generation tool (google search
CodeSmith) and (b) a professional O/R mapper (google search WilsonOR)

I love codesmith :)

Anyways, back to the topic..the benefit you gain with OO is more noticable
as your system grows complex. You'll see that your relational data doesn't
map so well to your object world (google search Object-Relational impedence
mismatch). A classic example is inheritance which brings forth tremendous
benefits that you can't get from a more procedural technique.

A solution might be to use a Data Mapper Design pattern
(http://www.martinfowler.com/eaaCatalog/dataMapper.html). This would leave
your classes as more pure domain objects and move the mundane and repetivie
mapping to its own layer/class. Great for even more flexibility.

If you aren't taking advantage of encapsulation, abstraction, inheritance
and polymorphism in your classes, ask yourself if you could..or think ahead
and see if they might be necessary with future requirements. Chances ar the
flexibility you've given yourself by this approach will pay off for itself
...even if it seems a little straightforward now..

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/

"scottrm" <scottrm@.newsgroup.nospam> wrote in message
news:4A0BD364-9A7A-44E1-82DC-BFD4260F14D5@.microsoft.com...
> I am fairly new to oo design and I am looking at developing an object
> oriented asp.net application which will be built on top of a relational
> database. I have read quite a bit of the theory but find it hard to put it
> into practice. In particular I am confused in terms of interacting with
the
> database. It seems to me classes map quite closely to database tables and
I
> end up with a bunch of methods in each class which simply call stored
> procedures to do data access eg. AddOrder method in an Order class. In
that
> case oo design just seems like a wrapper on top of the database. I don't
see
> what is gained over just using procedural techniques to group related
> functions together into modules. I am sure I am missing something.
> Any pointers to get on the right track? Specific advice or samples of a
> good design would be more appreciated that a pointer to a general book
> (although if someone knows of something dealing with this specific problem
> that would be great.)
> --
> Scott
Although it is quite hard to learn initially, Enterprise Core Objects from
Borland is an excellent tool.

You design the model in UML, it generates the DB for you, and you work only
with objects (never the db).

My website howtodothings.com was written with it, and I don't have a single
SQL statement in the whole project.

--
Pete
====
Read or write articles on just about anything
http://www.HowToDoThings.com

My blog
http://blogs.slcdug.org/petermorris/
Hi Scott,

Well, it sounds like you're on the right track, believe it or not. You have
to look at the evloution of programming to understand it more clearly.

In the beginning (almost), code was simply instructions that were executed
in the order in which they appeared in the source. It was soon discovered,
however, that certain blocks of code were commonly executed again and again.
This was initially solved with GoTo statements, which instructed the
compiler to go to a certain location in the code, execute the instructions
there, and return to the point it left from. And this lasted a while.

As the size and complexity of programs grew, GoTo statements made for some
serious spaghetti code, which became hard to maintain and modify. The
concept of more ordered source code, using functions and sub-procedures was
introduced to make code easier to manage.

Of course, this convenience only lasted awhile, as programs grew more in
complexity, and multi-tasking operating systems were introduced. Believe it
or not, Windows 3.1 was written in C, not C++. It used a heck of a lot of
loops and nested loops to do multi-tasking, messaging, and so on. You can
imagine the difficulty in maintaining such a huge program, which was made up
essentially of a single set of instructions that was immense in size.

At this point, due to the complexity of programs, new data types were
introduced called "structures." A structure is simply a combination of
multiple data and types of data into a single unit. It made code
organization easier, and a structure could hold both State and Process. In
other words, a member of a structure could be a piece of data, such as an
integer, or it could be a process, such as a function. Are we starting to
sound a little familiar at this point? We should be.

Enter Object-Oriented programming. Structures evolved into
objects/types/classes. OOP enhanced the structure concept, and added a few
of its own:

Inheritance: Inheritance performs much the same function as functions and
sub-procedures in terms of what its purpose is. By defining a base class,
and inheriting it, one could build multiple classes that shared some of the
same state and process, but with additional characteristics as well. In
addition, the developer doesn't have to re-write the same code to create a
new class. The code in a class is relatively lean, as much of the code
resides in the base class. This makes code maintenance and debugging much
easier.

Encapsulation: OOP introduced the idea of hiding members of a class in a
variety of ways. By doing so, the possible errors that could occur were
minimized. Only the members necessary to access fro outside the class are
exposed. There is no way that something outside the class can modify
something that it should not. This also enhances code maintenance and
debugging, by reducing the number of variables that can affect performance
of the app.

Polymorphism: Plolymorphism was actually introduced in earlier procedural
languages, with the concept of overloaded functions, by defining a function
as accepting different data types, and behaving differently when using them.
Classes extend the concept with overrides and other similar mechanisms that
allow a class to behave differently in different circumstances.

Abstraction: A little harder to define. Abstraction is an outgrowth of
encapsulation, in a sense. By hiding the details of how an object performs
its tasks, other objects can treat the class as if it were a "machine" that
performs some task, rather than a set of instructions. This also simplifies
code creation and maintenance.

All of this has come about as a result of computer and software evolution.
Just as Assembler language was developed to reduce the amount of time
necessary to write an application in machine code, each evolutionary stage
of programming technology is designed to reduce the amount of time and
resources necessary to write, debug, and maintain software.

The better your object model, the easier and quicker you can write
applications with it. If you're wise, you will create re-usable classes that
will continually reduce the amount of time and effort spent in future
development.

So, in conclusion, what is gained by OOP is the same thing that is gained
with "just using procedural techniques to group related functions together
into modules." It is simply the next stage in the evloution of programming.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"scottrm" <scottrm@.newsgroup.nospam> wrote in message
news:4A0BD364-9A7A-44E1-82DC-BFD4260F14D5@.microsoft.com...
>I am fairly new to oo design and I am looking at developing an object
> oriented asp.net application which will be built on top of a relational
> database. I have read quite a bit of the theory but find it hard to put it
> into practice. In particular I am confused in terms of interacting with
> the
> database. It seems to me classes map quite closely to database tables and
> I
> end up with a bunch of methods in each class which simply call stored
> procedures to do data access eg. AddOrder method in an Order class. In
> that
> case oo design just seems like a wrapper on top of the database. I don't
> see
> what is gained over just using procedural techniques to group related
> functions together into modules. I am sure I am missing something.
> Any pointers to get on the right track? Specific advice or samples of a
> good design would be more appreciated that a pointer to a general book
> (although if someone knows of something dealing with this specific problem
> that would be great.)
> --
> Scott
Hi Scott,

On top of what's been said, the fact that your db classes are just
wrappers for the db allows for a very academic N-Tiers architecture.
Down the road, N-Tiers is (are?) safer and less error-prone.

PS : and if you read Kevin's answer, you'll see that oo teaches you to
be both synthetic and crystal-clear. Nice piece, Kevin.

HTH,

Michel

"=?Utf-8?B?c2NvdHRybQ==?=" <scottrm@.newsgroup.nospam> wrote in message news:<4A0BD364-9A7A-44E1-82DC-BFD4260F14D5@.microsoft.com>...
> I am fairly new to oo design and I am looking at developing an object
> oriented asp.net application which will be built on top of a relational
> database. I have read quite a bit of the theory but find it hard to put it
> into practice. In particular I am confused in terms of interacting with the
> database. It seems to me classes map quite closely to database tables and I
> end up with a bunch of methods in each class which simply call stored
> procedures to do data access eg. AddOrder method in an Order class. In that
> case oo design just seems like a wrapper on top of the database. I don't see
> what is gained over just using procedural techniques to group related
> functions together into modules. I am sure I am missing something.
> Any pointers to get on the right track? Specific advice or samples of a
> good design would be more appreciated that a pointer to a general book
> (although if someone knows of something dealing with this specific problem
> that would be great.)

object oriented design books

Any recommendations for a good book/article/sample on object oriented design
particularly with regards to building an asp.net/sql server application. I
don't mean a book explaining concepts like inheritance etc. but one that
actually tells you how to design a system. I have read a few and although
they sound ok in theory they tend to be rather impractial when it actually
comes to implementing anything.
--
ScottThere are an infinite number of potential applications, and therefore an
infinite number of ways to design them.
This book is great for helping you figure out how to design the object model
behind large and complex applications:
Expert One-on-One Visual Basic .NET Business Objects (by Rockford Lhotka)
http://www.amazon.com/exec/obidos/A...3&link_code=as1
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net
"scottrm" <scottrm@.newsgroup.nospam> wrote in message
news:4A9F0DBD-7A30-4EC8-9D79-E9B6F00C31EE@.microsoft.com...
> Any recommendations for a good book/article/sample on object oriented
> design
> particularly with regards to building an asp.net/sql server application. I
> don't mean a book explaining concepts like inheritance etc. but one that
> actually tells you how to design a system. I have read a few and although
> they sound ok in theory they tend to be rather impractial when it actually
> comes to implementing anything.
> --
> Scott

object oriented design books

Any recommendations for a good book/article/sample on object oriented design
particularly with regards to building an asp.net/sql server application. I
don't mean a book explaining concepts like inheritance etc. but one that
actually tells you how to design a system. I have read a few and although
they sound ok in theory they tend to be rather impractial when it actually
comes to implementing anything.
--
ScottThere are an infinite number of potential applications, and therefore an
infinite number of ways to design them.
This book is great for helping you figure out how to design the object model
behind large and complex applications:

Expert One-on-One Visual Basic .NET Business Objects (by Rockford Lhotka)
http://www.amazon.com/exec/obidos/A...3&link_code=as1

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net

"scottrm" <scottrm@.newsgroup.nospam> wrote in message
news:4A9F0DBD-7A30-4EC8-9D79-E9B6F00C31EE@.microsoft.com...
> Any recommendations for a good book/article/sample on object oriented
> design
> particularly with regards to building an asp.net/sql server application. I
> don't mean a book explaining concepts like inheritance etc. but one that
> actually tells you how to design a system. I have read a few and although
> they sound ok in theory they tend to be rather impractial when it actually
> comes to implementing anything.
> --
> Scott

object oriented question

Hello all,

I have an object in business layer called
JPPage
Which has the properties:
id
title
content
parent
level

what I want to know is. I have a crumb trail on my front end which
only requires the properties id and title. So do I use a collection of
JPPage objects (even though the JPPage object has more properties that
I need for my crumb trail) or do I create a crumb trail object with
properties id and title? If I do this then in essense I have duplicate
code.

Or do I create an object, for example, called JPSimplePage with the
properties id and title and then create an object JPPage which
inherits JPSimplePage and has the additional properties of content,
parent and level?

Thanks in advance, just want to get my OO methology correct.

thanks
RussRussell,
First off, I don't see anything overly wrong with having a collection of
JPPage objects which only have a couple of their properties set. The only
real problem I see is that people might try to access other properties -
since it's fairly reasonable to expect the entire set of properties to be
properly set.

I think your inheritance idea is the way to go. This way there's no
confusion about what data is available when.

KArl

--
MY ASP.Net tutorials
http://www.openmymind.net/

"Russell" <russell8mccloy@.hotmail.com> wrote in message
news:15098e16.0411250431.6fcaa40d@.posting.google.c om...
> Hello all,
> I have an object in business layer called
> JPPage
> Which has the properties:
> id
> title
> content
> parent
> level
> what I want to know is. I have a crumb trail on my front end which
> only requires the properties id and title. So do I use a collection of
> JPPage objects (even though the JPPage object has more properties that
> I need for my crumb trail) or do I create a crumb trail object with
> properties id and title? If I do this then in essense I have duplicate
> code.
> Or do I create an object, for example, called JPSimplePage with the
> properties id and title and then create an object JPPage which
> inherits JPSimplePage and has the additional properties of content,
> parent and level?
> Thanks in advance, just want to get my OO methology correct.
> thanks
> Russ

cheers Karl.. I thought you might say that. Im loving OO. no more
spagetti code!!

RuSs

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Russell if you have duplicate code then you may need a further level in your
hierarchy

How about:

BaseObject
id

CrumbObject : BaseObject
title

JPPage : CrumObject
content
parent
level

MattC

"Russell" <russell8mccloy@.hotmail.com> wrote in message
news:15098e16.0411250431.6fcaa40d@.posting.google.c om...
> Hello all,
> I have an object in business layer called
> JPPage
> Which has the properties:
> id
> title
> content
> parent
> level
> what I want to know is. I have a crumb trail on my front end which
> only requires the properties id and title. So do I use a collection of
> JPPage objects (even though the JPPage object has more properties that
> I need for my crumb trail) or do I create a crumb trail object with
> properties id and title? If I do this then in essense I have duplicate
> code.
> Or do I create an object, for example, called JPSimplePage with the
> properties id and title and then create an object JPPage which
> inherits JPSimplePage and has the additional properties of content,
> parent and level?
> Thanks in advance, just want to get my OO methology correct.
> thanks
> Russ