Should I make lots of objects? :-)

[Simon]

Hi all,

I'm hoping that someone could help with the following general question:

I'm making a website that manages beta releases of software. It does various
things like store bugs, comments, work arounds and feature requests. Users
can subscribe to be notified if a feature or bug is detected in their area
of interest.

The software developer can publish new and polls and all sorts of crap like
that.

My question is, is it good practice to create a class or struct for nearly
all the nouns in the statements above.

I currently have classes representing Users, Roles, Permissions.

I'm wondering if I should create classes for things like bus, comment,
feature requests and so on or should I just pass around datasets and
datarows to represent the data and have other classes work on those data
collections.

If I should use custom objects for most of these requirements should I
always initialise them in the data layer before passing them back up to the
buisiness tier?

Thanks to any advice you can offer.

Kindest Regards

tce

[UAError]

"Simon" <sh856531@microsofts_free_email_service.com> wrote:

Hi all,

I'm hoping that someone could help with the following general question:

I'm making a website that manages beta releases of software. It does various
things like store bugs, comments, work arounds and feature requests. Users
can subscribe to be notified if a feature or bug is detected in their area
of interest.

The software developer can publish new and polls and all sorts of crap like
that.

My question is, is it good practice to create a class or struct for nearly
all the nouns in the statements above.

I currently have classes representing Users, Roles, Permissions.
Please tell me that you have looked into GenericIdentity,
GenericPrincipal, IIdentity, IPrincipal first?

..NET Framework Class Library GenericIdentity Class
http://msdn.microsoft.com/library/de...classtopic.asp

..NET Framework Class Library: GenericPrincipal Class
http://msdn.microsoft.com/library/de...classtopic.asp

..NET Framework Class Library IIdentity Interface
http://msdn.microsoft.com/library/de...classtopic.asp

..NET Framework Class Library IPrincipal Interface
http://msdn.microsoft.com/library/de...classtopic.asp

..NET Framework Class Library CodeAccessPermission Class
http://msdn.microsoft.com/library/de...classtopic.asp

..NET Framework Developer's Guide Permissions
http://msdn.microsoft.com/library/de...ermissions.asp

I'm wondering if I should create classes for things like bus, comment,
feature requests and so on or should I just pass around datasets and
datarows to represent the data and have other classes work on those data
collections.

Depends - if this is a simple application that won't change
much once its built then you can get away with the "Smart
UI" approach.

If this is something that may need to change continually it
may be worth the effort to model YOUR business of issue
management right now so that you can reap the benefits later
- if you feel up to the task. However creating lots of
different classes left, right and center is usually a bad
idea - it usually is a sign that you haven't explored the
commonalities and differences of your system's entities
enough.

If I should use custom objects for most of these requirements should I
always initialise them in the data layer before passing them back up to the
buisiness tier?

Thanks to any advice you can offer.

Kindest Regards

tce

[Peter Rilling]

I have no problem with lots of objects as long is it does not impede on
performance. Usually it will take a hell of a lot of objects before
performance will degrade.

In past projects that I have worked on, I find it beneficial to defined
objects and initialize them in the data layer. Basically, the data layer
reads the information from the database and sets the necessary properties.
That way the consuming code does not need to be aware of issues like row and
column format of the dataset. It also helps the compiler perform type
checking if you use actual objects. Objects are just easier to use and are
for the most part self documenting. Suppose that you have an object called
Comment with a property called Text. It is easier to read this then to get
row X, column Y of some dataset.

This is just my opinion and others may view things differently but I find
that the benefits outweigh the consequences.

Now, there is something that you might want to consider, whether you want to
communicate a lot with the database or store all those objects in memory.
One idea might be that if you create an object hierarchy, you might not want
to load some objects until they are actually used. There is no point in
having something in memory that might never be used. Therefore whenever you
call a property, it can call the data layer to initialize the information
and return what you expect. Or you could load all information when the
highest level object is created.

"Simon" <sh856531@microsofts_free_email_service.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

Hi all,

I'm hoping that someone could help with the following general question:

I'm making a website that manages beta releases of software. It does
various things like store bugs, comments, work arounds and feature
requests. Users can subscribe to be notified if a feature or bug is
detected in their area of interest.

The software developer can publish new and polls and all sorts of crap
like that.

My question is, is it good practice to create a class or struct for nearly
all the nouns in the statements above.

I currently have classes representing Users, Roles, Permissions.

I'm wondering if I should create classes for things like bus, comment,
feature requests and so on or should I just pass around datasets and
datarows to represent the data and have other classes work on those data
collections.

If I should use custom objects for most of these requirements should I
always initialise them in the data layer before passing them back up to
the buisiness tier?

Thanks to any advice you can offer.

Kindest Regards

tce

[thechaosengine]

Thanks for the advice.

I've looked at the built in authentication classes in .net. I don't like
them and want to make my own. Simple as that.

Simon

[xxx]

Sorry, I didn't quite get that. What do you mean?

"thechaosengine" wrote:

Thanks for the advice.

I've looked at the built in authentication classes in .net. I don't like
them and want to make my own. Simple as that.

Simon

[Bruce Wood]

The short answer is yes.

For me, it is a simple choice between two alternatives:

1. Pass all data around in raw DataSets. Have application code operate
on those DataSets. This means, for example, that the code for
manipulating a Bug report (accepting a new one, updating one, attaching
it to a code change, closing one) is spread over a half dozen Forms.
Now someone asks me to add a new field to a Bug report, so I have to go
hunting throughout all of my Forms, and the hunt isn't easy, as the
only thing I have to help me is some column names. Or,

2. Create an object for every different kind of thing I'm manipulating
in my application, whether or not I choose to continue to hold my data
in DataSets. Even if a DataSet, or a DataRow is my preferred way of
storing information in memory, I have at least gathered all of the
operations that I'm allowed to perform with a Bug in one class, in one
spot. If that behaviour has to change, I know where to go. If I'm
looking for which Forms display the BugNumber, for example, I can
search on the property name of the class, rather than just a column
name.

Now, just because you create an object hierarchy does _not_ mean that
you can't use DataSets to store your data. In my case, I went whole hog
and copied the data out of the data sets into the objects' private
fields, but that's only one possibility. Regardless of how you
implement the classes, you should certainly use the class hierarchy as
a tool to organize your code.

Only a very, very simple application can afford to have its business
logic coded into a Form somewhere. What you're doing sounds moderately
complex.