Class Design and Re-use

[krs]

Hi,
I'm using the MS timetracker app as a basis for an application I am building.

I have at present two classes, Site and SitesCollection, similar to the timeentry and timeentrycollection classes. These classes use the ms sqlhelper class as a data access layer.

I've now created a web form that uses the site and sitescollection classes to build a collection of site objects from the database and display them in a datagrid. I have also provided fields to allow for adding sites to the db and allowed users to edit inline and delete by choosing a checkbox and hitting a delete button.

My question is around how I would now provide the same maintenance page for a different set of data. Sites contain pages, so I am allowing the user to choose a site from the grid to display the related pages in the same manner as for sites.

I'm thinking the best way is to now create a page and pagescollection class and then follow the same principle with datagrid, inputs, buttons etc as for the sites. I'm concerned though that I will be repeating code that could in some way be re-used.

Am I approaching this correctly or is there a better way to go about this sort of problem?

Any suggestions greatly appreciated.

Thanks
K

[Jeremy]

Here's my 2-cents worth on your specific question <<Am I approaching this
correctly or is there a better way to go about this sort of problem?>>
We all want to re-use as much code as possible for a variety of lofty
reasons. So the fact that you're on the lookout for an opportunity to re-use
your code means you are starting out on the right track. Now, in your
particular situation, it's hard to say whether you can completely re-use
your Site and SiteCollection classes or if you can partially re-use them
(abstracting some functionality into one or more base classes that are then
extended for unique entities). In fact, it might be hard for you to know
ahead of time whether you could re-use them. If you were perfectly clear on
the requirements (i.e., all the properties and methods of each), then you
could know ahead of time where all the similarities and differences are
(between {Sites/SiteCollection} and {Site/SitePages}), and therefore the
extent to which you could re-use your classes (perhaps renaming them to
something more generic in the process to facilitate maintenance and
readability of your code). However, a strong case could be made that you
will not (and cannot) be totally clear on the requirements until after you
have finished implementing the requirements to the user's satisfaction (I'm
assuming you have a non trivial project on your hands with real end-users).
Now, once you have implemented everything to the user's satisfaction, then
you can have total clarity on the specs for your classes - and would then be
in a position to refactor all of your app's classes - determining which
functionality can be abstracted... which base classes could be created, etc.
My hunch is that if you were more clear on the requirements that you
wouldn't be asking us this question and would be proceeding ahead with
confidence. So, given that you aren't totally clear (forgive me if I'm
wrong - it's happened before!), I'd suggest that you proceed with any way
you can see to make it work. Then when you feel you have enough clarity you
can refactor your code to make your final implementation more maintainable,
readable, extensible, blah blah blah.

Good Luck...

-J

MCSD, MCDBA, MCSE, MCSA (FWIW - which may not be much!)

"krs" <kr*@discussions.microsoft.com> wrote in message
news:C4**********************************@microsof t.com...

Hi,
I'm using the MS timetracker app as a basis for an application I am building.
I have at present two classes, Site and SitesCollection, similar to the timeentry and timeentrycollection classes. These classes use the ms
sqlhelper class as a data access layer.
I've now created a web form that uses the site and sitescollection classes to build a collection of site objects from the database and display them in
a datagrid. I have also provided fields to allow for adding sites to the db
and allowed users to edit inline and delete by choosing a checkbox and
hitting a delete button.
My question is around how I would now provide the same maintenance page for a different set of data. Sites contain pages, so I am allowing the user
to choose a site from the grid to display the related pages in the same
manner as for sites.
I'm thinking the best way is to now create a page and pagescollection class and then follow the same principle with datagrid, inputs, buttons etc
as for the sites. I'm concerned though that I will be repeating code that
could in some way be re-used.
Am I approaching this correctly or is there a better way to go about this sort of problem?
Any suggestions greatly appreciated.

Thanks
K

[krs]

Thanks for your input.

So I guess for now I'll leave the different classes seperate for Sites, SitesCollection, Page, PagesCollection. Do you think there is a way I could be re-using the code that I have written in the .aspx page that uses these classes? I currently have a page written that allows me to maintain the database for sites, update, delete, add etc...

I now need to do exactly the same thing for pages, though pages will have different data, in effect I still want to do add, update and delete. I dont think that lifting the code from one page and creating another for pages is the best option, should I be thinking along the lines of a server control, that implements the logic of the datagrid?

I hope this makes sense.

Thanks
K

"Jeremy" wrote:

Here's my 2-cents worth on your specific question <<Am I approaching this
correctly or is there a better way to go about this sort of problem?>>
We all want to re-use as much code as possible for a variety of lofty
reasons. So the fact that you're on the lookout for an opportunity to re-use
your code means you are starting out on the right track. Now, in your
particular situation, it's hard to say whether you can completely re-use
your Site and SiteCollection classes or if you can partially re-use them
(abstracting some functionality into one or more base classes that are then
extended for unique entities). In fact, it might be hard for you to know
ahead of time whether you could re-use them. If you were perfectly clear on
the requirements (i.e., all the properties and methods of each), then you
could know ahead of time where all the similarities and differences are
(between {Sites/SiteCollection} and {Site/SitePages}), and therefore the
extent to which you could re-use your classes (perhaps renaming them to
something more generic in the process to facilitate maintenance and
readability of your code). However, a strong case could be made that you
will not (and cannot) be totally clear on the requirements until after you
have finished implementing the requirements to the user's satisfaction (I'm
assuming you have a non trivial project on your hands with real end-users).
Now, once you have implemented everything to the user's satisfaction, then
you can have total clarity on the specs for your classes - and would then be
in a position to refactor all of your app's classes - determining which
functionality can be abstracted... which base classes could be created, etc.
My hunch is that if you were more clear on the requirements that you
wouldn't be asking us this question and would be proceeding ahead with
confidence. So, given that you aren't totally clear (forgive me if I'm
wrong - it's happened before!), I'd suggest that you proceed with any way
you can see to make it work. Then when you feel you have enough clarity you
can refactor your code to make your final implementation more maintainable,
readable, extensible, blah blah blah.

Good Luck...

-J

MCSD, MCDBA, MCSE, MCSA (FWIW - which may not be much!)

"krs" <kr*@discussions.microsoft.com> wrote in message
news:C4**********************************@microsof t.com...

Hi,
I'm using the MS timetracker app as a basis for an application I am

building.

I have at present two classes, Site and SitesCollection, similar to the

timeentry and timeentrycollection classes. These classes use the ms
sqlhelper class as a data access layer.

I've now created a web form that uses the site and sitescollection classes

to build a collection of site objects from the database and display them in
a datagrid. I have also provided fields to allow for adding sites to the db
and allowed users to edit inline and delete by choosing a checkbox and
hitting a delete button.

My question is around how I would now provide the same maintenance page

for a different set of data. Sites contain pages, so I am allowing the user
to choose a site from the grid to display the related pages in the same
manner as for sites.

I'm thinking the best way is to now create a page and pagescollection

class and then follow the same principle with datagrid, inputs, buttons etc
as for the sites. I'm concerned though that I will be repeating code that
could in some way be re-used.

Am I approaching this correctly or is there a better way to go about this

sort of problem?

Any suggestions greatly appreciated.

Thanks
K

[krs]

Thanks for your input.

So I guess for now I'll leave the different classes seperate for Sites, SitesCollection, Page, PagesCollection. Do you think there is a way I could be re-using the code that I have written in the .aspx page that uses these classes? I currently have a page written that allows me to maintain the database for sites, update, delete, add etc...

I now need to do exactly the same thing for pages, though pages will have different data, in effect I still want to do add, update and delete. I dont think that lifting the code from one page and creating another for pages is the best option, should I be thinking along the lines of a server control, that implements the logic of the datagrid?

I hope this makes sense.

Thanks
K

"Jeremy" wrote:

Here's my 2-cents worth on your specific question <<Am I approaching this
correctly or is there a better way to go about this sort of problem?>>
We all want to re-use as much code as possible for a variety of lofty
reasons. So the fact that you're on the lookout for an opportunity to re-use
your code means you are starting out on the right track. Now, in your
particular situation, it's hard to say whether you can completely re-use
your Site and SiteCollection classes or if you can partially re-use them
(abstracting some functionality into one or more base classes that are then
extended for unique entities). In fact, it might be hard for you to know
ahead of time whether you could re-use them. If you were perfectly clear on
the requirements (i.e., all the properties and methods of each), then you
could know ahead of time where all the similarities and differences are
(between {Sites/SiteCollection} and {Site/SitePages}), and therefore the
extent to which you could re-use your classes (perhaps renaming them to
something more generic in the process to facilitate maintenance and
readability of your code). However, a strong case could be made that you
will not (and cannot) be totally clear on the requirements until after you
have finished implementing the requirements to the user's satisfaction (I'm
assuming you have a non trivial project on your hands with real end-users).
Now, once you have implemented everything to the user's satisfaction, then
you can have total clarity on the specs for your classes - and would then be
in a position to refactor all of your app's classes - determining which
functionality can be abstracted... which base classes could be created, etc.
My hunch is that if you were more clear on the requirements that you
wouldn't be asking us this question and would be proceeding ahead with
confidence. So, given that you aren't totally clear (forgive me if I'm
wrong - it's happened before!), I'd suggest that you proceed with any way
you can see to make it work. Then when you feel you have enough clarity you
can refactor your code to make your final implementation more maintainable,
readable, extensible, blah blah blah.

Good Luck...

-J

MCSD, MCDBA, MCSE, MCSA (FWIW - which may not be much!)

"krs" <kr*@discussions.microsoft.com> wrote in message
news:C4**********************************@microsof t.com...

Hi,
I'm using the MS timetracker app as a basis for an application I am

building.

I have at present two classes, Site and SitesCollection, similar to the

timeentry and timeentrycollection classes. These classes use the ms
sqlhelper class as a data access layer.

I've now created a web form that uses the site and sitescollection classes

to build a collection of site objects from the database and display them in
a datagrid. I have also provided fields to allow for adding sites to the db
and allowed users to edit inline and delete by choosing a checkbox and
hitting a delete button.

My question is around how I would now provide the same maintenance page

for a different set of data. Sites contain pages, so I am allowing the user
to choose a site from the grid to display the related pages in the same
manner as for sites.

I'm thinking the best way is to now create a page and pagescollection

class and then follow the same principle with datagrid, inputs, buttons etc
as for the sites. I'm concerned though that I will be repeating code that
could in some way be re-used.

Am I approaching this correctly or is there a better way to go about this

sort of problem?

Any suggestions greatly appreciated.

Thanks
K

[krs]

Thanks for your input.

So I guess for now I'll leave the different classes seperate for Sites, SitesCollection, Page, PagesCollection. Do you think there is a way I could be re-using the code that I have written in the .aspx page that uses these classes? I currently have a page written that allows me to maintain the database for sites, update, delete, add etc...

I now need to do exactly the same thing for pages, though pages will have different data, in effect I still want to do add, update and delete. I dont think that lifting the code from one page and creating another for pages is the best option, should I be thinking along the lines of a server control, that implements the logic of the datagrid?

I hope this makes sense.

Thanks
K

"Jeremy" wrote:

Here's my 2-cents worth on your specific question <<Am I approaching this
correctly or is there a better way to go about this sort of problem?>>
We all want to re-use as much code as possible for a variety of lofty
reasons. So the fact that you're on the lookout for an opportunity to re-use
your code means you are starting out on the right track. Now, in your
particular situation, it's hard to say whether you can completely re-use
your Site and SiteCollection classes or if you can partially re-use them
(abstracting some functionality into one or more base classes that are then
extended for unique entities). In fact, it might be hard for you to know
ahead of time whether you could re-use them. If you were perfectly clear on
the requirements (i.e., all the properties and methods of each), then you
could know ahead of time where all the similarities and differences are
(between {Sites/SiteCollection} and {Site/SitePages}), and therefore the
extent to which you could re-use your classes (perhaps renaming them to
something more generic in the process to facilitate maintenance and
readability of your code). However, a strong case could be made that you
will not (and cannot) be totally clear on the requirements until after you
have finished implementing the requirements to the user's satisfaction (I'm
assuming you have a non trivial project on your hands with real end-users).
Now, once you have implemented everything to the user's satisfaction, then
you can have total clarity on the specs for your classes - and would then be
in a position to refactor all of your app's classes - determining which
functionality can be abstracted... which base classes could be created, etc.
My hunch is that if you were more clear on the requirements that you
wouldn't be asking us this question and would be proceeding ahead with
confidence. So, given that you aren't totally clear (forgive me if I'm
wrong - it's happened before!), I'd suggest that you proceed with any way
you can see to make it work. Then when you feel you have enough clarity you
can refactor your code to make your final implementation more maintainable,
readable, extensible, blah blah blah.

Good Luck...

-J

MCSD, MCDBA, MCSE, MCSA (FWIW - which may not be much!)

"krs" <kr*@discussions.microsoft.com> wrote in message
news:C4**********************************@microsof t.com...

Hi,
I'm using the MS timetracker app as a basis for an application I am building.

I have at present two classes, Site and SitesCollection, similar to the

timeentry and timeentrycollection classes. These classes use the ms
sqlhelper class as a data access layer.

I've now created a web form that uses the site and sitescollection classes

to build a collection of site objects from the database and display them in
a datagrid. I have also provided fields to allow for adding sites to the db
and allowed users to edit inline and delete by choosing a checkbox and
hitting a delete button.

My question is around how I would now provide the same maintenance page

for a different set of data. Sites contain pages, so I am allowing the user
to choose a site from the grid to display the related pages in the same
manner as for sites.

I'm thinking the best way is to now create a page and pagescollection

class and then follow the same principle with datagrid, inputs, buttons etc
as for the sites. I'm concerned though that I will be repeating code that
could in some way be re-used.

Am I approaching this correctly or is there a better way to go about this

sort of problem?

Any suggestions greatly appreciated.

Thanks
K

"Jeremy" wrote:
Here's my 2-cents worth on your specific question <<Am I approaching this
correctly or is there a better way to go about this sort of problem?>>
We all want to re-use as much code as possible for a variety of lofty
reasons. So the fact that you're on the lookout for an opportunity to re-use
your code means you are starting out on the right track. Now, in your
particular situation, it's hard to say whether you can completely re-use
your Site and SiteCollection classes or if you can partially re-use them
(abstracting some functionality into one or more base classes that are then
extended for unique entities). In fact, it might be hard for you to know
ahead of time whether you could re-use them. If you were perfectly clear on
the requirements (i.e., all the properties and methods of each), then you
could know ahead of time where all the similarities and differences are
(between {Sites/SiteCollection} and {Site/SitePages}), and therefore the
extent to which you could re-use your classes (perhaps renaming them to
something more generic in the process to facilitate maintenance and
readability of your code). However, a strong case could be made that you
will not (and cannot) be totally clear on the requirements until after you
have finished implementing the requirements to the user's satisfaction (I'm
assuming you have a non trivial project on your hands with real end-users).
Now, once you have implemented everything to the user's satisfaction, then
you can have total clarity on the specs for your classes - and would then be
in a position to refactor all of your app's classes - determining which
functionality can be abstracted... which base classes could be created, etc.
My hunch is that if you were more clear on the requirements that you
wouldn't be asking us this question and would be proceeding ahead with
confidence. So, given that you aren't totally clear (forgive me if I'm
wrong - it's happened before!), I'd suggest that you proceed with any way
you can see to make it work. Then when you feel you have enough clarity you
can refactor your code to make your final implementation more maintainable,
readable, extensible, blah blah blah.

Good Luck...

-J

MCSD, MCDBA, MCSE, MCSA (FWIW - which may not be much!)

"krs" <kr*@discussions.microsoft.com> wrote in message
news:C4**********************************@microsof t.com...

Hi,
I'm using the MS timetracker app as a basis for an application I am

building.

I have at present two classes, Site and SitesCollection, similar to the

timeentry and timeentrycollection classes. These classes use the ms
sqlhelper class as a data access layer.

I've now created a web form that uses the site and sitescollection classes

to build a collection of site objects from the database and display them in
a datagrid. I have also provided fields to allow for adding sites to the db
and allowed users to edit inline and delete by choosing a checkbox and
hitting a delete button.

My question is around how I would now provide the same maintenance page

for a different set of data. Sites contain pages, so I am allowing the user
to choose a site from the grid to display the related pages in the same
manner as for sites.

I'm thinking the best way is to now create a page and pagescollection

class and then follow the same principle with datagrid, inputs, buttons etc
as for the sites. I'm concerned though that I will be repeating code that
could in some way be re-used.

Am I approaching this correctly or is there a better way to go about this

sort of problem?

Any suggestions greatly appreciated.

Thanks
K

[krs]

Thanks for your input.

So I guess for now I'll leave the different classes seperate for Sites, SitesCollection, Page, PagesCollection. Do you think there is a way I could be re-using the code that I have written in the .aspx page that uses these classes? I currently have a page written that allows me to maintain the database for sites, update, delete, add etc...

I now need to do exactly the same thing for pages, though pages will have different data, in effect I still want to do add, update and delete. I dont think that lifting the code from one page and creating another for pages is the best option, should I be thinking along the lines of a server control, that implements the logic of the datagrid?

I hope this makes sense.

Thanks
K

"Jeremy" wrote:

Here's my 2-cents worth on your specific question <<Am I approaching this
correctly or is there a better way to go about this sort of problem?>>
We all want to re-use as much code as possible for a variety of lofty
reasons. So the fact that you're on the lookout for an opportunity to re-use
your code means you are starting out on the right track. Now, in your
particular situation, it's hard to say whether you can completely re-use
your Site and SiteCollection classes or if you can partially re-use them
(abstracting some functionality into one or more base classes that are then
extended for unique entities). In fact, it might be hard for you to know
ahead of time whether you could re-use them. If you were perfectly clear on
the requirements (i.e., all the properties and methods of each), then you
could know ahead of time where all the similarities and differences are
(between {Sites/SiteCollection} and {Site/SitePages}), and therefore the
extent to which you could re-use your classes (perhaps renaming them to
something more generic in the process to facilitate maintenance and
readability of your code). However, a strong case could be made that you
will not (and cannot) be totally clear on the requirements until after you
have finished implementing the requirements to the user's satisfaction (I'm
assuming you have a non trivial project on your hands with real end-users).
Now, once you have implemented everything to the user's satisfaction, then
you can have total clarity on the specs for your classes - and would then be
in a position to refactor all of your app's classes - determining which
functionality can be abstracted... which base classes could be created, etc.
My hunch is that if you were more clear on the requirements that you
wouldn't be asking us this question and would be proceeding ahead with
confidence. So, given that you aren't totally clear (forgive me if I'm
wrong - it's happened before!), I'd suggest that you proceed with any way
you can see to make it work. Then when you feel you have enough clarity you
can refactor your code to make your final implementation more maintainable,
readable, extensible, blah blah blah.

Good Luck...

-J

MCSD, MCDBA, MCSE, MCSA (FWIW - which may not be much!)

"krs" <kr*@discussions.microsoft.com> wrote in message
news:C4**********************************@microsof t.com...

Hi,
I'm using the MS timetracker app as a basis for an application I am

building.

I have at present two classes, Site and SitesCollection, similar to the

timeentry and timeentrycollection classes. These classes use the ms
sqlhelper class as a data access layer.

I've now created a web form that uses the site and sitescollection classes

to build a collection of site objects from the database and display them in
a datagrid. I have also provided fields to allow for adding sites to the db
and allowed users to edit inline and delete by choosing a checkbox and
hitting a delete button.

My question is around how I would now provide the same maintenance page

for a different set of data. Sites contain pages, so I am allowing the user
to choose a site from the grid to display the related pages in the same
manner as for sites.

I'm thinking the best way is to now create a page and pagescollection

class and then follow the same principle with datagrid, inputs, buttons etc
as for the sites. I'm concerned though that I will be repeating code that
could in some way be re-used.

Am I approaching this correctly or is there a better way to go about this

sort of problem?

Any suggestions greatly appreciated.

Thanks
K

[krs]

Thanks for your input.

So I guess for now I'll leave the different classes seperate for Sites, SitesCollection, Page, PagesCollection. Do you think there is a way I could be re-using the code that I have written in the .aspx page that uses these classes? I currently have a page written that allows me to maintain the database for sites, update, delete, add etc...

I now need to do exactly the same thing for pages, though pages will have different data, in effect I still want to do add, update and delete. I dont think that lifting the code from one page and creating another for pages is the best option, should I be thinking along the lines of a server control, that implements the logic of the datagrid?

I hope this makes sense.

Thanks
K

"Jeremy" wrote:

Here's my 2-cents worth on your specific question <<Am I approaching this
correctly or is there a better way to go about this sort of problem?>>
We all want to re-use as much code as possible for a variety of lofty
reasons. So the fact that you're on the lookout for an opportunity to re-use
your code means you are starting out on the right track. Now, in your
particular situation, it's hard to say whether you can completely re-use
your Site and SiteCollection classes or if you can partially re-use them
(abstracting some functionality into one or more base classes that are then
extended for unique entities). In fact, it might be hard for you to know
ahead of time whether you could re-use them. If you were perfectly clear on
the requirements (i.e., all the properties and methods of each), then you
could know ahead of time where all the similarities and differences are
(between {Sites/SiteCollection} and {Site/SitePages}), and therefore the
extent to which you could re-use your classes (perhaps renaming them to
something more generic in the process to facilitate maintenance and
readability of your code). However, a strong case could be made that you
will not (and cannot) be totally clear on the requirements until after you
have finished implementing the requirements to the user's satisfaction (I'm
assuming you have a non trivial project on your hands with real end-users).
Now, once you have implemented everything to the user's satisfaction, then
you can have total clarity on the specs for your classes - and would then be
in a position to refactor all of your app's classes - determining which
functionality can be abstracted... which base classes could be created, etc.
My hunch is that if you were more clear on the requirements that you
wouldn't be asking us this question and would be proceeding ahead with
confidence. So, given that you aren't totally clear (forgive me if I'm
wrong - it's happened before!), I'd suggest that you proceed with any way
you can see to make it work. Then when you feel you have enough clarity you
can refactor your code to make your final implementation more maintainable,
readable, extensible, blah blah blah.

Good Luck...

-J

MCSD, MCDBA, MCSE, MCSA (FWIW - which may not be much!)

"krs" <kr*@discussions.microsoft.com> wrote in message
news:C4**********************************@microsof t.com...

Hi,
I'm using the MS timetracker app as a basis for an application I am

building.

I have at present two classes, Site and SitesCollection, similar to the

timeentry and timeentrycollection classes. These classes use the ms
sqlhelper class as a data access layer.

I've now created a web form that uses the site and sitescollection classes

to build a collection of site objects from the database and display them in
a datagrid. I have also provided fields to allow for adding sites to the db
and allowed users to edit inline and delete by choosing a checkbox and
hitting a delete button.

My question is around how I would now provide the same maintenance page

for a different set of data. Sites contain pages, so I am allowing the user
to choose a site from the grid to display the related pages in the same
manner as for sites.

I'm thinking the best way is to now create a page and pagescollection

class and then follow the same principle with datagrid, inputs, buttons etc
as for the sites. I'm concerned though that I will be repeating code that
could in some way be re-used.

Am I approaching this correctly or is there a better way to go about this

sort of problem?

Any suggestions greatly appreciated.

Thanks
K

[krs]

Thanks for your input.

So I guess for now I'll leave the different classes seperate for Sites, SitesCollection, Page, PagesCollection. Do you think there is a way I could be re-using the code that I have written in the .aspx page that uses these classes? I currently have a page written that allows me to maintain the database for sites, update, delete, add etc...

I now need to do exactly the same thing for pages, though pages will have different data, in effect I still want to do add, update and delete. I dont think that lifting the code from one page and creating another for pages is the best option, should I be thinking along the lines of a server control, that implements the logic of the datagrid?

I hope this makes sense.

Thanks
K

"Jeremy" wrote:

Here's my 2-cents worth on your specific question <<Am I approaching this
correctly or is there a better way to go about this sort of problem?>>
We all want to re-use as much code as possible for a variety of lofty
reasons. So the fact that you're on the lookout for an opportunity to re-use
your code means you are starting out on the right track. Now, in your
particular situation, it's hard to say whether you can completely re-use
your Site and SiteCollection classes or if you can partially re-use them
(abstracting some functionality into one or more base classes that are then
extended for unique entities). In fact, it might be hard for you to know
ahead of time whether you could re-use them. If you were perfectly clear on
the requirements (i.e., all the properties and methods of each), then you
could know ahead of time where all the similarities and differences are
(between {Sites/SiteCollection} and {Site/SitePages}), and therefore the
extent to which you could re-use your classes (perhaps renaming them to
something more generic in the process to facilitate maintenance and
readability of your code). However, a strong case could be made that you
will not (and cannot) be totally clear on the requirements until after you
have finished implementing the requirements to the user's satisfaction (I'm
assuming you have a non trivial project on your hands with real end-users).
Now, once you have implemented everything to the user's satisfaction, then
you can have total clarity on the specs for your classes - and would then be
in a position to refactor all of your app's classes - determining which
functionality can be abstracted... which base classes could be created, etc.
My hunch is that if you were more clear on the requirements that you
wouldn't be asking us this question and would be proceeding ahead with
confidence. So, given that you aren't totally clear (forgive me if I'm
wrong - it's happened before!), I'd suggest that you proceed with any way
you can see to make it work. Then when you feel you have enough clarity you
can refactor your code to make your final implementation more maintainable,
readable, extensible, blah blah blah.

Good Luck...

-J

MCSD, MCDBA, MCSE, MCSA (FWIW - which may not be much!)

"krs" <kr*@discussions.microsoft.com> wrote in message
news:C4**********************************@microsof t.com...

Hi,
I'm using the MS timetracker app as a basis for an application I am building.

I have at present two classes, Site and SitesCollection, similar to the

timeentry and timeentrycollection classes. These classes use the ms
sqlhelper class as a data access layer.

I've now created a web form that uses the site and sitescollection classes

to build a collection of site objects from the database and display them in
a datagrid. I have also provided fields to allow for adding sites to the db
and allowed users to edit inline and delete by choosing a checkbox and
hitting a delete button.

My question is around how I would now provide the same maintenance page

for a different set of data. Sites contain pages, so I am allowing the user
to choose a site from the grid to display the related pages in the same
manner as for sites.

I'm thinking the best way is to now create a page and pagescollection

class and then follow the same principle with datagrid, inputs, buttons etc
as for the sites. I'm concerned though that I will be repeating code that
could in some way be re-used.

Am I approaching this correctly or is there a better way to go about this

sort of problem?

Any suggestions greatly appreciated.

Thanks
K

"Jeremy" wrote:
Here's my 2-cents worth on your specific question <<Am I approaching this
correctly or is there a better way to go about this sort of problem?>>
We all want to re-use as much code as possible for a variety of lofty
reasons. So the fact that you're on the lookout for an opportunity to re-use
your code means you are starting out on the right track. Now, in your
particular situation, it's hard to say whether you can completely re-use
your Site and SiteCollection classes or if you can partially re-use them
(abstracting some functionality into one or more base classes that are then
extended for unique entities). In fact, it might be hard for you to know
ahead of time whether you could re-use them. If you were perfectly clear on
the requirements (i.e., all the properties and methods of each), then you
could know ahead of time where all the similarities and differences are
(between {Sites/SiteCollection} and {Site/SitePages}), and therefore the
extent to which you could re-use your classes (perhaps renaming them to
something more generic in the process to facilitate maintenance and
readability of your code). However, a strong case could be made that you
will not (and cannot) be totally clear on the requirements until after you
have finished implementing the requirements to the user's satisfaction (I'm
assuming you have a non trivial project on your hands with real end-users).
Now, once you have implemented everything to the user's satisfaction, then
you can have total clarity on the specs for your classes - and would then be
in a position to refactor all of your app's classes - determining which
functionality can be abstracted... which base classes could be created, etc.
My hunch is that if you were more clear on the requirements that you
wouldn't be asking us this question and would be proceeding ahead with
confidence. So, given that you aren't totally clear (forgive me if I'm
wrong - it's happened before!), I'd suggest that you proceed with any way
you can see to make it work. Then when you feel you have enough clarity you
can refactor your code to make your final implementation more maintainable,
readable, extensible, blah blah blah.

Good Luck...

-J

MCSD, MCDBA, MCSE, MCSA (FWIW - which may not be much!)

"krs" <kr*@discussions.microsoft.com> wrote in message
news:C4**********************************@microsof t.com...

Hi,
I'm using the MS timetracker app as a basis for an application I am

building.

I have at present two classes, Site and SitesCollection, similar to the

timeentry and timeentrycollection classes. These classes use the ms
sqlhelper class as a data access layer.

I've now created a web form that uses the site and sitescollection classes

to build a collection of site objects from the database and display them in
a datagrid. I have also provided fields to allow for adding sites to the db
and allowed users to edit inline and delete by choosing a checkbox and
hitting a delete button.

My question is around how I would now provide the same maintenance page

for a different set of data. Sites contain pages, so I am allowing the user
to choose a site from the grid to display the related pages in the same
manner as for sites.

I'm thinking the best way is to now create a page and pagescollection

class and then follow the same principle with datagrid, inputs, buttons etc
as for the sites. I'm concerned though that I will be repeating code that
could in some way be re-used.

Am I approaching this correctly or is there a better way to go about this

sort of problem?

Any suggestions greatly appreciated.

Thanks
K