Model-View-Controller implementation question in .NET

[Griff]

Two questions really, the first one "conceptual" and the other more involved
with design:

1 - There are two schools of thought where I work on the role of the
"controller" task.

The first is that the business object will provide the business rules and
that the controller will implement the rules and then pass the result set to
the view (i.e. do most of the grunt work).

So for example, the business object may have two methods. The first one
provides a list of menu items and the second provides a list of who can see
what. The controller then prunes the list of menu items down to those that
can be accessed by the particular user and passes the result to the view.

The second is that the business object has one method that gives the menu
items that the end user can see and the controller simply passes this to the
view. (i.e. the BO does most of the grunt work and the controller just has
the logic of knowing where to get this data and where to send it - i.e.,to
the view).

Personally, I subscribe to the second one. The reason is that if I have one
BO that happens to be consumed by n controllers, then I don't want to
replicate the implementation of the business rules n times, just the once.

However, what is the general consensus of opinion?

2 - I've just read in an article "MVC infrastructure that doesn't harm
ASP.NET mechanism" that implementing the MVC pattern isn't truly compatible
with the ASP.NET 2.0 framework: http://www.codeproject.com/aspnet/NWAF.asp

Do people concur with this?

If so, what advice can people give me? I've got to re-write a CLASSIC ASP
eCommerce application that is not that complicated a site in terms of the
number of pages etc, but it does have a heavy load (it's a B2B system with ~
3/4 million users)

Thanks in advance

Griff

[C.C. \(aka Me\)]

The idea behind MVC is that the Data (Model) is hidden from the outside
world. That way if it changes, or how you implement it changes, the outside
world does not care/know. The Controller (API) is what the outside world
uses to gain access to the data but in a non-data-implementation-specific
format (ie. you dont want to return a Collection because later on you may
change to use a fixed array of objects instead.)

Example:
A class that keeps track of people. The person calling the controller has no
idea that the Model uses collections to keep track of data, or that there
are 2 different collections in use (one for age and one for name). If I
decide to change how I store the data later on (maybe I will store the data
in a database instead of in memory) the outside world would not have to
change how they access the Controller because the API they are using does
not change.

public class Controller
{
private Model m_model;

public int Count
{
{ get m_model.m_names.Count; }
}

public string GetName(int index)
{
return (string)m_model.m_names[index];
}

public int GetAge(int index)
{
return (int)m_model.m_ages[index];
}

public itn AddPerson(string name, int age)
{
m_model.m_names.Add(name);
m_model.m_names.Add(age);
}
}

public class Model
{
public ArrayList m_names;
public ArrayList m_ages;
}

Hope this helps!

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Griff" <Ho*****@The.Moon> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Two questions really, the first one "conceptual" and the other more
involved with design:

1 - There are two schools of thought where I work on the role of the
"controller" task.

The first is that the business object will provide the business rules and
that the controller will implement the rules and then pass the result set
to the view (i.e. do most of the grunt work).

So for example, the business object may have two methods. The first one
provides a list of menu items and the second provides a list of who can
see what. The controller then prunes the list of menu items down to those
that can be accessed by the particular user and passes the result to the
view.

The second is that the business object has one method that gives the menu
items that the end user can see and the controller simply passes this to
the view. (i.e. the BO does most of the grunt work and the controller
just has the logic of knowing where to get this data and where to send
it - i.e.,to the view).

Personally, I subscribe to the second one. The reason is that if I have
one BO that happens to be consumed by n controllers, then I don't want to
replicate the implementation of the business rules n times, just the once.

However, what is the general consensus of opinion?

2 - I've just read in an article "MVC infrastructure that doesn't harm
ASP.NET mechanism" that implementing the MVC pattern isn't truly
compatible with the ASP.NET 2.0 framework:
http://www.codeproject.com/aspnet/NWAF.asp

Do people concur with this?

If so, what advice can people give me? I've got to re-write a CLASSIC ASP
eCommerce application that is not that complicated a site in terms of the
number of pages etc, but it does have a heavy load (it's a B2B system with
~ 3/4 million users)

Thanks in advance

Griff

[Griff]

Hi Charles

Great simple example - thanks.

Just extending it a little....if you wanted to add a business rule to say
that a particular end user can NOT add users, then should you add this
business logic to the controller or should you incorporate it in the model
class?

I'm guessing that the Model is not just data but business rules too? Am I
wrong?

If I'm right then you'd have to call a method on the model class that adds
the new user to a PRIVATE array and this method has an additional argument
to say who is trying to add the new user and use a business rule to decide
whether or not the new user should be added.

Thanks

Griff

[C.C. \(aka Me\)]

I guess it depends on the situation and implementation of the particular
system. Take the following scenario as an example of what I mean.

You have a backend system (database) that has 2 different front ends (web
and desktop application). Now, the Web side you only want to allow Queries
to be done but the desktop app. can add/delete/etc. Both of the front ends
could use the same Model but use different Controllers to access it. The
business logic in this setup would probably be in the Controller since it
would be different between the two front ends. You would use two different
controllers as a security measure so that no matter what the Web front end
does not even have the "code" (Controller) to perform add/delete/etc.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Griff" <Ho*****@The.Moon> wrote in message
news:uA**************@TK2MSFTNGP12.phx.gbl...

Hi Charles

Great simple example - thanks.

Just extending it a little....if you wanted to add a business rule to say
that a particular end user can NOT add users, then should you add this
business logic to the controller or should you incorporate it in the model
class?

I'm guessing that the Model is not just data but business rules too? Am I
wrong?

If I'm right then you'd have to call a method on the model class that adds
the new user to a PRIVATE array and this method has an additional argument
to say who is trying to add the new user and use a business rule to decide
whether or not the new user should be added.

Thanks

Griff

[Griff]

CC - thanks!

Griff