Linq to Sql design and MVP

Question

I'm experimenting with LinqToSql and the MVP pattern and having trouble setting on a good design. I'm using Asp.net 3.5 (not MVC)

Here is a example

public interface IMyBusinessCardView
{
    string Field1 { get; set; }
    string Field2 { get; set; }
    string Field15 { get; set; }
}

public class MyBusinessCardPresenter
{
    private IMyBusinessCardView _view;
    private MyBusinessCard _myCard;

    public void ViewClickedSave()
    {
        _myCard.SaveNewBusinessCard(_view);
    }

    public void LoadView()
    {
        _myCard.LoadMyBusinessCardToView(_view);
    }
}

public class MyBusinessCard
{
    public void SaveNewBusinessCard(IMyBusinessCardView view)
    {
        using (var context = new DataContext())
        {
            var card = new BusinessCard()
            {
                Field1 = view.Field1
            };
            context.BusinessCards.InsertOnSubmit(card);
            context.SubmitChanges();
        }
    }

    public void LoadMyBusinessCardToView(IMyBusinessCardView view)
    {
        // Query using Linq to Sql and set in view
        view.Field1 = card.Fields1;
    }
}

I'm thinking The view and controller are very thin, that's good I guess. The "model" has access to the view, is that bad? Should I introduce DTO objects or should I use the LinqToSql generated entities.

Please provide feedback to the design.

Answer 1

Check out this project on codeplex for some inspiration http://www.codeplex.com/NSK

I'd also recommend reading the related book - it's an excellent read. http://www.amazon.co.uk/Microsoft-NET-Architecting-Applications-PRO-Developer/dp/073562609X

Answer 2

Hey,

In MVP, the bulk of the work should be in the presenter; the less the view knows about the presenter, the better. I haven't seen anything where the model works with the view; I've seen where the presenter does all of the coordination. With a single page, there could be multiple presenters to spread around the logic.

Check out the images in this for two types of MVP patterns (passive view and supervising controller): http://www.yeejie.com/blog/post/2009/01/19/MVP-Passive-View-Supervising-Controller-Presentation-Model.aspx

In this example, even though the view access the model in supervising controller, it doesn't actually operate on the view.

EDIT: just came across this framework: http://webformsmvp.codeplex.com/ as an implementation.

HTH.

Answer 3

Definitely not a good idea to tie knowledge of the view (or presenter) into the model.

If you use Linq-to-sql objects as model classes, then your view will end up with intimate knowledge of the data layer.

If the above two statements are acceptable, then that pretty much leaves DTO's as the answer.

Also, I've had good results from defining event properties on the Presenter, instead of a view interface. Makes it easier to unit-test specific cases, by just attaching to the relevant events.