MVP Pattern with .aspx Pages, and FXCop Error

[Chris Marsh]

All

In order to facilitate more effective unit testing for .aspx and .ascx
items, I am using the MVP pattern. I therefore have the following entities:

interface IMyPageView
class MyPagePresenter
class MyPage

Interface IMyPageView defines events.
Class MyPagePresenter accepts an object of type IMyPageView through its
constructor, and subscribes to the object's events.
Class MyPage implements IMyPageView, and invokes the required events in the
appropriate places. It also creates an instance of MyPagePresenter, passing
itself (MyPage) through the constructor.

All of this works fine; I'm satisfied that it effectively seperates
concerns, and the code is simple and maintainable. However, FXCop complains
that the variable within MyPage used to hold the reference to the instance
of MyPagePresenter is never assigned to. I am obliged to fix all FXCop
errors and warnings, and I cannot exclude any of them. Can anyone suggest
how I may circumvent this issue whilst maintaining this model and satisfying
FXCop?

The line causing FXCop problems within MyPage is:

MyPagePresenter presenter = new MyPagePresenter (this);

Many thanks in advance for your assistance in this matter!

 

[Peter Bromberg [C# MVP]]

Well, what does the constructor look like? Does it actually assign the passed
in page instance to a field or not? I ran FxCop against the Microsoft
Enterprise Library and got a liist of errors that would have kept me busy for
days...

--Peter
"Inside every large program, there is a small program trying to get out."
http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://www.blogmetafinder.com

 

[Chris Marsh]

Peter

Many thanks for the response.

Well, what does the constructor look like? Does it actually assign the
passed
in page instance to a field or not?

It does.

I had the thought that one way around it would be to perhaps call a dummy
method thus:

MyPagePresenter presenter = new MyPagePresenter (this);
presenter.DoesNothing();

But this is a cheap hack, which is not really what I want.

I ran FxCop against the Microsoft
Enterprise Library and got a liist of errors that would have kept me busy
for
days...

The environment that I'm developing in is heavily structured, and to check
code in it is required to pass all FXCop tests, unfortunately.

Thanks again!

 

[Scott Roberts]

I had the thought that one way around it would be to perhaps call a dummy
method thus:

MyPagePresenter presenter = new MyPagePresenter (this);
presenter.DoesNothing();

But this is a cheap hack, which is not really what I want.

How about this:

MyPagePresenter presenter = new MyPagePresenter();
presenter.MyPage = this;

It's pretty much the same cheap hack you described, but now the second line
of code actually does something. That may or may not help you sleep better
at night.

Scott

 

[Chris Marsh]

Scott

Thanks a lot for the input.

How about this:

MyPagePresenter presenter = new MyPagePresenter();
presenter.MyPage = this;

It's pretty much the same cheap hack you described, but now the second
line of code actually does something. That may or may not help you sleep
better at night.

That's something that I considered, but the issue with this is (I suppose)
that there is a risk that the object would not be in the correct state when
used. However, it's much better than my hack

Is it acceptable to check that the property has been set within my presenter
class and raising an exception if not? If so, would it be a
ConfigurationException that would be appropriate? If not, is there any other
way to enforce this?

Cheers!

 

[Scott Roberts]

Is it acceptable to check that the property has been set within my

presenter class and raising an exception if not? If so, would it be a
ConfigurationException that would be appropriate? If not, is there any
other way to enforce this?

Acceptable to who?

I can see both sides of this one. From a usability stand-point, it's more
difficult to use objects that have property/method dependencies. What
properties must I set before I use specific methods? It's not immediately
clear. Requiring a constructor arguement is very clear.

On the other hand, there's nothing inherently "wrong" with requiring that a
property be set before using a particular method. Look at the SqlCommand
class. You can create one without a SqlConnection, but you must set the
SqlConnection prior to calling any methods that actually try to execute SQL.
Same thing here.

It's really your call.

 

[Chris Marsh]

Scott

Many thanks for the advice. I shall consider things before proceeding.

Cheers!