I'm really looking more for validation here of my understanding of MVP before I approach the project lead about refactoring major pieces of our application...
We presently have an expanded MVP 开发者_JAVA技巧pattern where we have the following projects:
- Entity (Defines POCOs)
- Model (Defines data layer configurations (EF code first - not that it matters here))
- Task (all business logic in a well ordered grouping)
- Presenter (page (or page type) specific, calls tasks, defines and works with all View interfaces)
- View (in the form of different websites (internal, external))
Currently in the View layer I frequently see code that works directly with the Entities, so an ASPX page (could be php, whatever) which has to display a list of entries does so like this:
public interface IEntityList
{
ICollection<Entity> MyEntities {get;set;}
event EventHandler OnReportRunning;
}
public class EntityList : IEntityList
{
public ICollection<Entity> MyEntities {get;set;}
private void RenderEntities()
{
OnReportRunning(this, null);
if (MyEntities != null)
{
ArrayList entityList= new ArrayList();
foreach (var entity in Myentities.OrderBy(e=>e.Field))
{
var formatedEntity = new {FullName = String.Format("{0}, {1}",
entity.LastName, entity.FirstName), UserEmail = entity.Email};
entityList.Add(formatedEntity);
}
ddlEntities.DataSource = entityList;
ddlEntities.DataBind();
}
}
}
I'm of the opinion that this violates the intent of the presenter layer. I think the view should expose the DropDownList
(ddlEntities) or whatever other controls it has, and the presenter should be the point at which ALL knowledge of the Entity layer stops.
And thus my question - SHOULD the View (V) layer of an MVP (perhaps it should be MPV) architecture have any knowledge of the model (M)? Or am I right in thinking that the only work the View layer should do is direct reactions to events from the controls, and that all real presentation work (binding, formatting involving entities, etc) should be done in the presenter layer, and that the Presenter layer is SUPPOSED to be strongly aware of the actual View layer (IIS vs. Apache vs Mobile etc)?
What you are suggesting with the "only events" on the view is Passive View flavor of the MVP, I prefer the Supervising Controller, where you do everything except the data binding in the presenter. I usually have something like view.BindData()
in which view asks presenter for data and bind it (but of course, the presenter controls when the BindData()
will be called, so it ensures that there is some data to bind before the call is made).
I also think that event communication instead of directly calling presenter methods is a overkill in 95% of cases.
精彩评论