ASP.NET/OOP and adding specific logic to controls in overriden methods

[Bob Jones]

I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?

 

[Guest]

Howdy,

I have just one question ;-) What's the company name so i would know where
not to apply ;-)

 

[Bob Jones]

Howdy,

I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz









- Show quoted text -

Milosz,

Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.

=o)

 

[Bob Jones]

I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?

Just cross-posting this message

 

[Bob Jones]

I have an odd business requirement and I think that the implementation

 

[Bob Jones]

I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?

 

[Guest]

Hi Bob,

Sorry to say that, but I’m unable to help you, (to be honest) my point of
view at web architecture is completely different. I’m a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I’m usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it’s not possible to
cache everything), so it’s vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I’m really horrified. Let me explain
why:
• Try to reuse control elsewhere (meaning with different database schema you
simply can’t or it’s a big task
• Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it’s not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
• There are many dependencies, therefore every single developer involved
must know everything or almost everything, it’s difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
• You mentioned about database logic based on control id - it’s just
ridiculous (or I’m really missing something)

From my experience I know it’s easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline I‘m really serious about the company name Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)

Regards

Milosz

 

[Bob Jones]

Hi Bob,

Sorry to say that, but I'm unable to help you, (to be honest) my point of
view at web architecture is completely different. I'm a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I'm usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it's not possible to
cache everything), so it's vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I'm really horrified. Let me explain
why:
· Try to reuse control elsewhere (meaning with different database schema you
simply can't or it's a big task
· Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it's not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
· There are many dependencies, therefore every single developer involved
must know everything or almost everything, it's difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
· You mentioned about database logic based on control id - it's just
ridiculous (or I'm really missing something)

From my experience I know it's easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline I'm really serious about the company name Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)

Regards

Milosz






- Show quoted text -

Milosz,

I agree with everything you said and if I were to design this
application from scratch I would def. take a different approach.

The controls, however, are NOT databound but get information from a
caching sytem. But that was just information I gave out to give a
bigger picture. My question is basically the last part of my post.
Would it be better to make our custom Page object loop it's child
controls and call the appropiate methods (MyInit, MyRender) while
passing in needed data or would it be better to force the developers
to hard code methods in each control's OnInit and OnRender functions?

Obviously my take is the former so I can code against an Interface and
not rely on having junior level developers or contracts have to have a
manual next to them in order to write custom controls.

I cannot tell you the company name in the forums but if you would
like, send me an e-mail I can reply to and I will send you the name
(if you respond backto this post w/ your opinion). =o)

Regards,
Bob

 

[Guest]

I know i know there is nothing you can do

Another resolution would be to register every control that implements
IOurControl interface in base page as it can access containing page instance
via Page property (inside controls' oninit virtual method).

-- begin base page class --
.....
private System.Collections.Generic.List<IOurControl> ourControls = new
System.Collections.Generic.List<IOurControl>();

public System.Collections.Generic.List<IOurControl> OurControls
{
get
{
return this.ourControls;
}
}

protected override void OnPreRenderComplete(EventArgs e)
{
base.OnPreRenderComplete(e);

foreach (IOurControl control in ourControls)
{
control.OurInterfaceMethod();
}
}
-- end base page class --


-- control that implement IOurInterface --

protected override OnInit(object sender, EventArgs e)
{
base.OnInit(sender, e);

if (this.Page != null)
{
BasePageClassName basePage = (BasePageClassName) this.Page;
basePage.OurControls.Add((IOurInterface) this);
}
}


--
Milosz

Hi Bob,

Sorry to say that, but I'm unable to help you, (to be honest) my point of
view at web architecture is completely different. I'm a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I'm usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it's not possible to
cache everything), so it's vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I'm really horrified. Let me explain
why:
· Try to reuse control elsewhere (meaning with different database schema you
simply can't or it's a big task
· Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it's not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
· There are many dependencies, therefore every single developer involved
must know everything or almost everything, it's difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
· You mentioned about database logic based on control id - it's just
ridiculous (or I'm really missing something)

From my experience I know it's easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline I'm really serious about the company name Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)

Regards

Milosz

On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
Howdy,

I have just one question ;-) What's the company name so i would know where
not to apply ;-)

:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?- Hide quoted text -

- Show quoted text -

Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.

=o)- Hide quoted text -

- Show quoted text -

Milosz,

I agree with everything you said and if I were to design this
application from scratch I would def. take a different approach.

The controls, however, are NOT databound but get information from a
caching sytem. But that was just information I gave out to give a
bigger picture. My question is basically the last part of my post.
Would it be better to make our custom Page object loop it's child
controls and call the appropiate methods (MyInit, MyRender) while
passing in needed data or would it be better to force the developers
to hard code methods in each control's OnInit and OnRender functions?

Obviously my take is the former so I can code against an Interface and
not rely on having junior level developers or contracts have to have a
manual next to them in order to write custom controls.

I cannot tell you the company name in the forums but if you would
like, send me an e-mail I can reply to and I will send you the name
(if you respond backto this post w/ your opinion). =o)

Regards,
Bob

 

[Bob Jones]

I know i know there is nothing you can do

Another resolution would be to register every control that implements
IOurControl interface in base page as it can access containing page instance
via Page property (inside controls' oninit virtual method).

-- begin base page class --
....
private System.Collections.Generic.List<IOurControl> ourControls = new
System.Collections.Generic.List<IOurControl>();

public System.Collections.Generic.List<IOurControl> OurControls
{
get
{
return this.ourControls;
}

}

protected override void OnPreRenderComplete(EventArgs e)
{
base.OnPreRenderComplete(e);

foreach (IOurControl control in ourControls)
{
control.OurInterfaceMethod();
}}

-- end base page class --

-- control that implement IOurInterface --

protected override OnInit(object sender, EventArgs e)
{
base.OnInit(sender, e);

if (this.Page != null)
{
BasePageClassName basePage = (BasePageClassName) this.Page;
basePage.OurControls.Add((IOurInterface) this);
}

}

--
Milosz

Hi Bob,
Sorry to say that, but I'm unable to help you, (to be honest) my point of
view at web architecture is completely different. I'm a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I'm usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it's not possible to
cache everything), so it's vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I'm really horrified. Let me explain
why:
· Try to reuse control elsewhere (meaning with different database schema you
simply can't or it's a big task
· Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it's not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
· There are many dependencies, therefore every single developer involved
must know everything or almost everything, it's difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
· You mentioned about database logic based on control id - it's just
ridiculous (or I'm really missing something)
From my experience I know it's easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline I'm really serious about the company name Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)
Regards
Milosz
:
On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
Howdy,
I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz
:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!
We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).
What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.
Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.
Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?- Hide quoted text -
- Show quoted text -
Milosz,
Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.
=o)- Hide quoted text -
- Show quoted text -

Milosz,

I agree with everything you said and if I were to design this
application from scratch I would def. take a different approach.

The controls, however, are NOT databound but get information from a
caching sytem. But that was just information I gave out to give a
bigger picture. My question is basically the last part of my post.
Would it be better to make our custom Page object loop it's child
controls and call the appropiate methods (MyInit, MyRender) while
passing in needed data or would it be better to force the developers
to hard code methods in each control's OnInit and OnRender functions?

Obviously my take is the former so I can code against an Interface and
not rely on having junior level developers or contracts have to have a
manual next to them in order to write custom controls.

I cannot tell you the company name in the forums but if you would
like, send me an e-mail I can reply to and I will send you the name
(if you respond backto this post w/ your opinion). =o)

Regards,
Bob- Hide quoted text -

- Show quoted text -

Milosz,

Thanks for the code sample, so you do agree that having the page
control interate the child controls and calling the proper methods IS
the more proper way to go?

Bob

 

[Guest]

Yes, but not enumertating all the controls in tree, just those that are
registered. Have you checked email box ? ;-)
--
Milosz

I know i know there is nothing you can do

Another resolution would be to register every control that implements
IOurControl interface in base page as it can access containing page instance
via Page property (inside controls' oninit virtual method).

-- begin base page class --
....
private System.Collections.Generic.List<IOurControl> ourControls = new
System.Collections.Generic.List<IOurControl>();

public System.Collections.Generic.List<IOurControl> OurControls
{
get
{
return this.ourControls;
}

}

protected override void OnPreRenderComplete(EventArgs e)
{
base.OnPreRenderComplete(e);

foreach (IOurControl control in ourControls)
{
control.OurInterfaceMethod();
}}

-- end base page class --

-- control that implement IOurInterface --

protected override OnInit(object sender, EventArgs e)
{
base.OnInit(sender, e);

if (this.Page != null)
{
BasePageClassName basePage = (BasePageClassName) this.Page;
basePage.OurControls.Add((IOurInterface) this);
}

}

--
Milosz

On Feb 27, 11:52 am, Milosz Skalecki [MCAD]
Hi Bob,

Sorry to say that, but I'm unable to help you, (to be honest) my point of
view at web architecture is completely different. I'm a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I'm usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it's not possible to
cache everything), so it's vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I'm really horrified. Let me explain
why:
· Try to reuse control elsewhere (meaning with different database schema you
simply can't or it's a big task
· Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it's not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
· There are many dependencies, therefore every single developer involved
must know everything or almost everything, it's difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
· You mentioned about database logic based on control id - it's just
ridiculous (or I'm really missing something)

From my experience I know it's easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline I'm really serious about the company name Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)

Regards

Milosz

:
On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
Howdy,

I have just one question ;-) What's the company name so i would know where
not to apply ;-)

:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?- Hide quoted text -

- Show quoted text -

Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.

=o)- Hide quoted text -

- Show quoted text -

I agree with everything you said and if I were to design this
application from scratch I would def. take a different approach.

The controls, however, are NOT databound but get information from a
caching sytem. But that was just information I gave out to give a
bigger picture. My question is basically the last part of my post.
Would it be better to make our custom Page object loop it's child
controls and call the appropiate methods (MyInit, MyRender) while
passing in needed data or would it be better to force the developers
to hard code methods in each control's OnInit and OnRender functions?

Obviously my take is the former so I can code against an Interface and
not rely on having junior level developers or contracts have to have a
manual next to them in order to write custom controls.

I cannot tell you the company name in the forums but if you would
like, send me an e-mail I can reply to and I will send you the name
(if you respond backto this post w/ your opinion). =o)

Regards,
Bob- Hide quoted text -

- Show quoted text -

Milosz,

Thanks for the code sample, so you do agree that having the page
control interate the child controls and calling the proper methods IS
the more proper way to go?

Bob

 

[Bob Jones]

Yes, but not enumertating all the controls in tree, just those that are
registered. Have you checked email box ? ;-)
--
Milosz

I know i know there is nothing you can do
Another resolution would be to register every control that implements
IOurControl interface in base page as it can access containing page instance
via Page property (inside controls' oninit virtual method).
-- begin base page class --
....
private System.Collections.Generic.List<IOurControl> ourControls = new
System.Collections.Generic.List<IOurControl>();
public System.Collections.Generic.List<IOurControl> OurControls
{
get
{
return this.ourControls;
}
}
protected override void OnPreRenderComplete(EventArgs e)
{
base.OnPreRenderComplete(e);
foreach (IOurControl control in ourControls)
{
control.OurInterfaceMethod();
}}
-- end base page class --
-- control that implement IOurInterface --
protected override OnInit(object sender, EventArgs e)
{
base.OnInit(sender, e);
if (this.Page != null)
{
BasePageClassName basePage = (BasePageClassName) this.Page;
basePage.OurControls.Add((IOurInterface) this);
}
}
--
Milosz
:
On Feb 27, 11:52 am, Milosz Skalecki [MCAD]
Hi Bob,
Sorry to say that, but I'm unable to help you, (to be honest) my point of
view at web architecture is completely different. I'm a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I'm usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it's not possible to
cache everything), so it's vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I'm really horrified. Let me explain
why:
· Try to reuse control elsewhere (meaning with different database schema you
simply can't or it's a big task
· Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it's not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
· There are many dependencies, therefore every single developer involved
must know everything or almost everything, it's difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
· You mentioned about database logic based on control id - it's just
ridiculous (or I'm really missing something)
From my experience I know it's easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline I'm really serious about the company name Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)
Regards
Milosz
:
On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
Howdy,
I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz
:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!
We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).
What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.
Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.
Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?- Hide quoted text -
- Show quoted text -
Milosz,
Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.
=o)- Hide quoted text -
- Show quoted text -
Milosz,
I agree with everything you said and if I were to design this
application from scratch I would def. take a different approach.
The controls, however, are NOT databound but get information from a
caching sytem. But that was just information I gave out to give a
bigger picture. My question is basically the last part of my post.
Would it be better to make our custom Page object loop it's child
controls and call the appropiate methods (MyInit, MyRender) while
passing in needed data or would it be better to force the developers
to hard code methods in each control's OnInit and OnRender functions?
Obviously my take is the former so I can code against an Interface and
not rely on having junior level developers or contracts have to have a
manual next to them in order to write custom controls.
I cannot tell you the company name in the forums but if you would
like, send me an e-mail I can reply to and I will send you the name
(if you respond backto this post w/ your opinion). =o)
Regards,
Bob- Hide quoted text -
- Show quoted text -

Milosz,

Thanks for the code sample, so you do agree that having the page
control interate the child controls and calling the proper methods IS
the more proper way to go?

Bob- Hide quoted text -

- Show quoted text -

Thanks for the help and the code, Milosz. Ya got mail, btw.


If anyone else cares to add their two cents, please feel free

 

[Bob Jones]

I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?

Seriously? No body has any comments on this matter?