How to implement paging in ASP.NET webforms when applying the MVP pattern? I'm wondering where to put the paging logic...in the view or in the presenter? Also a neet way to implement paging in ASP.NET is to use the PagedDataSource control... would it be correct to use that from a presenter or would we better of implementing some custom paging logic. The data is displayed in the view using a Repeater control.
I don't know exactly, what difference is there between mvp and mvc, so I think this post might be useful to you. I personally like the idea to create a hepler outside model or controller(presenter?). Also jquery paging mechanism is pretty straight forward. In presenter just add parameters for requested rows of data and return only those instead of whole table/grid/whatever.
I think both the View and the Presenter need to know about paging. Here's why:
Intelligent paging should only retrieve data needed to fill a page. This is a collaboration between the Presenter and the Model in my mind. In pedantic MVP, the View has no knowledge of the Model, so the Presenter must be the go-between. In MVC, you might get away with excluding the Controller with a strong enough domain model.
The View needs to know about paging so that the user can interact properly with the paging metaphore (Next, Prev, proper rendering, etc)
I'm not terribly familiar with the PagedDataSource. If you're using WebForms, you're probably hosed if you want to stick to a faithful implementation of MVP. Perhaps you could set up the page caching for the PagedDataSource (if there is such a thing) in the Presenter and the GUI glamour in the View. It would mean passing around a reference to a user control, but maybe that's okay.
Kudos to you for trying to make MVP work with WebForms. I'd love to hear how it turns out.
Related
(Apologies for the vagueness of this question. It is the result of some muddy thinking on my part.)
I am designing a small website with an MSSQL DB. I have just stumbled across the ObjectDataSource class. I think I understand it, but I don't see how it relates to the traditional MVC design pattern, if at all.
The class, according to Microsoft, is designed to sit between the UI (View) and the database, and as such, I would think of it as a Controller. It does indeed map UI actions to behaviours, but it also contains code for writing to the database, which is not something I would expect a Controller to do (but I may be wrong).
It seems to me that it is both the Controller and the Model, but I get the feeling I am not seeing something here.
That's a lot of words to say I am very confused. I would be very grateful to anyone who can point me at anything that might help me to understand what I am missing here.
The purpose of the ObjectDataSource is to intermediate between the view and some code that retrieves your data, not to the database directly. It is not a controller, but something that would call your code to get the data. A better description would be from an MVP scenario, where in MVP the view can manage itself, and the ObjectDataSource is a control that makes that management easier. However, the ObjectDataSource may make it harder to work with a traditional MVP or MVC design implementation out of the box, depending on the framework setup.
I personally don't like this control; I never use it as I'd rather code it so it's easier to see how the binding takes place, in addition to when the binding takes place. My personal opinion.
ObjectDataSource is not used in asp.net MVC if that's what you mean "traditional MVC design pattern". It's used primarily in WebForms development.
It's usually dropped onto a webform component and configured via the UI, although it doesn't have to be. It provides an abstraction that allows other WebForms controls to interact with an object model in a manner that is similar to the way in which these controls work with Databases. This object model may ultimately come from a database, but it allows you to insert your own database methodology in between.
WebForms does not lend itself to the traditional MVC pattern due to some technical issues which complicate using it in that way. A cleaner pattern for use with WebForms is the MVP (Model View Presenter) pattern.
This is a question I asked myself many times. My company uses WebForms, and always I start developing a new application, my problem is managing controls state. With control state I mean things like: "If this ListBox is empty, disable this button, if this GridView is in edit mode and there is a row selected, disable that TextBox, if this button is pressed, refill the DetailsView, etc." Normally, when I finish coding the WebForms application, I have written a lot of code to control all those controls state in the same Page, and that code is messy and error prone. Are there any tecnics I can apply for improving and order the Page's code (distributing it in other clases, for example)?
I've seen some examples of WebForms code where the pages state is controlled using the MVP (Model-View-Presenter) pattern.
The MVP pattern is a variant of the MVC pattern where you have a Presenter class that controls the state of you page. It allows you to extract the code that controls state into a class that is both testable and reusable.
Moving to the MVP pattern if you have used "traditional" WebForms for a while can be challenging, but it will give you much cleaner code if you do it right.
An old but ok article on WebForms and MVP can be found here: http://msdn.microsoft.com/en-us/magazine/ff955232.aspx
You should also google the concept, there are many articles on the subject out there. :-)
You can make it more cleaner using custom userControls.
It's reusable and the code logic is not in your "master" page
I am an asp.net beginner and thinking about designing a website with a typically Master-Detail view. There is a GridView-Control which is displaying all Records and Detail view below to edit existing records, add new ones and display one in detail.
There are several controls in asp.net which can handle such situations: GridView in combination with DetailsView or FormView. But all these approaches do have in common that they seems to be designed for Rapid application development. I want to use my own DAL and so on, so I need to have full control over Insert/Update statements for example.
Whats the typical asp.net approach for dealing with this?
Should I create a UserControl for the Detail view which saves its state (View/Edit/... mode) on its own? Furthermore the view differs only slightly with its state (for example the Insert view does have one more Input-control than the edit view). It seems that the mentioned DetailsView and FormView cannot handle this either and so I have a lot of copy&paste like code.
I think thats all a pretty common situation. What do you prefer in those situations?
You can bind manually data from your custom DAL to the DetailsView or FormView directly like so:
this.dvw.DataSource = new[] { DAL.GetObject(1) };
this.dvw.DataBind();
Or you can also use the ObjectDataSource, which wires up to your DAL object and invokes the method when it needs it.
You can also use a custom user control and load the data manually, which is an approach I have taken in my applications too.
It really depends on your architecture, what you want to achieve, how complex your object model is, and a variety of other factors.
For the Master part, I build the interface by hand, I mean, creating textboxes, labels, etc.
For the Details part, I use a editable GridView. This a tedious task.
Of course, you can use some scaffolding to generate ASP.Net code for your UI from the database model.
You can check this: http://codepaste.net/b1geac
I am quite amused by the MVP Pattern http://webformsmvp.com/
How ever I have certain doubts on the implementation part.
Is it necessary that to use this pattern, I have to implement user controls?
I always thought that user controls are created if we need reuse of controls across pages.
Say if I want to implement and test MVP pattern,I should break my simple page with controls to a lot of user controls so that I can apply the MVP pattern?
What if I have quite a lot of standalone components in my webpage?
Is there any gap in my understanding of MVP?
Help.
It is not necessary to implement user controls to use this pattern, in short. Very briefly, you need a view (could be aspx or wpf or winform or console, etc.), a presenter that'll read from/listen to events from the view, make a call to the model and finally populate view with the right data, that's what MVP pattern is.
edit: this example is simple enough.
You don't have to use user control to use MVP pattern. MVP is GUI pattern that helps you to separate your concern.
For example, You write ASP.NET web page to calculate two numbers, with out MVP or MVC or any other GUI pattern, you would write all this logic in your code behind file which is very hard to test. If you want to test it, then you are bringing lot of extra baggages like ASP.NET framework.
In other hand, you write this app using MVP, you would do this.
View => Dumbest in all three. Doesnt have any or minimun logic. So you dont have to unit test it. It simply "tells" the presenter something happened and does what presenter asks.
Presenter => Controls the flow
Model => Business Logic/persistent logic.
I'm the author of the Web Forms MVP project you mention. This answer is specific to that library (which is just one implementation of the MVP pattern).
No, you do not need to use user controls. If you want, you can make your page inherit from MvpPage and it will then work with a presenter itself.
We recommend that you do use user controls though, even if you aren't using the control multiple times in your site. This lets you keep the view, view model and presenter logic nice and bundled as a logical unit for a particular feature. Pages are then used purely for laying out controls.
I have looked around on the Internet trying to answer this question. It seems to be kind of complicated though! Seems to come up with all sorts of different topics such as the HtmlHelper and other stuff.
Basically. How can you use custom controls with MVC? In a way that avoids doing anything that is frowned upon.
Also, Is it true that with MVC you have to put some simple logic IN THE PAGE? Isn't that what we should be getting away from?
Update: So, Seems you cannot use controls which depend on anything which MVC does away with, such as the postback events and viewstate. Can you make your own then? A control which does only rendering of course.
Can you use ASP.NET controls? Maybe. If the control does not use ViewState or postback events, it will probably work. For example, the LoginView control works just fine. Telerik supports ASP.NET MVC with some of their controls. On the other hand, if the control needs either ViewState or postbacks, then it just isn't going to work. Controls with data binding aren't ideal, since you typically have to use code behind him up. But they will work, if you add code behind.
On the other hand, controls with no knowledge of ASP.NET (such as the jQuery UI controls) work very well.
No, you don't have to put your logic in the page. You just don't put it on a code behind page, either. Instead, use helper methods.
With respect to the second question, the page is exactly where view logic should go. Any other logic should be in your controllers or models.
I'm not sure what you mean by custom controls. You can have ViewUserControls that are rendered via partials to reuse view code. If you are talking about 3rd part controls built for webforms, it's likely they won't work -- at least for awhile. If you absolutely must have them, though, there are ways to mix MVC with traditional webforms in the same site.