I am trying to implement the MVP design pattern for the first time, using webforms and SQL Server.
I want to use a Gridview to display data from the database.
However when I set the ControlSource of the Gridview from the Presenter, it makes the Default.aspx View dependent on the Dataset. This seems wrong, because if I swap my SQL database for something else, the view would have to change as the GridView might not work.
Is it bad practice to do this, if so how can it be avoided?
I have added my notes to help illustrate the problem (note the red arrow between DefaultView and Dataset):
I really can't understand why, having such rich model layer, would you ignore it and bind the view directly to a data set. Why on Earth you don't bind to a list of objects exposed in the model?
Grids in ASP.NET do fine if you bind to IEnumerables, a list of object is fine. You could even have a thin adapter, the ObjectDataSource that controls the way a grid retrieves and updates the data to support sorting and paging.
So, answering your question:
Is it bad practice to do this, if so how can it be avoided?
To me, the view peeks too deep under the cover, it actually peeks into internal details of the DAO implementation. You could avoid it by coupling the view to the model members instead of the model internals. And while your model looks OOP (Customer), data set sounds like the internal way the db access is implemented.
BTW. I would consider switching to an ORM like Entity Framework. It makes implementing object models much easier than introducing a layer of data sets.
Related
I realize this doesn't necessarily apply to MVC exclusively, but bear with me.
Working with entity framework and models, I've read several articles on "best practices" where some people claim using repositories and unit of work is better, others claim it's overkill and using your models directly within your controllers with linq is better, so on and so forth...
Then we have view-models and lazy loading methods, but then with linq we can use joins to add multiple "models" to our data retrieval to fetch whatever we need directly in our controller or helper class.
I realize a lot of this ties back to the "separation of concerns" that is MVC and we can create multiple layers to map our data back whichever way we want, which is great, but let's say for argument sake my app run exclusively on MS SQL, with no chance of ever transitioning to another database type, will adding all the additional layers of separation to map data back give me any real benefit? I'm just trying to understand at which point does one conclude it's better to do it this way over that way? I know some of this might consist of personal preference, but I'm looking for REAL LIFE scenarios where it's easy for me to conclude one way it better than the other AND what questions I should ask myself when deciding how many mapping layers do I need to get my data from my database to my view?
One of the real benefits is when your models or your UI need to change independently of each other. If your view is only tied to a ViewModel instead of your entity, then you can make all of the mapping changes in one place (your controller) instead of needing to go through every view that your entity is being used and making changes there. Also, with ViewModels, you have the benefit of combining multiple data sources into a single object. Basically, you get a lot more flexibility in how to implement your UI if you don't tie it directly to database tables.
A colleague of mine doesn't want to bind from the View directly to the Model. For example, in the Model, he has a ObservableCollection and in the View he wants to use it. Instead of directly using it like I would do it (e.g. {Binding Model.Collection} he has another ObservableCollection in the ViewModel which has exactly the same data as the ObservableCollection in the Model. He is synchronizing both ObservableCollections with each other through events.
What are the benefits of his approach? I, personally, disapprove of his approach because it just adds duplicate code and since you have to synchronize the ObservableCollections yourself it's also more error prone. My colleague says he wants to do it this way because then he can change the Model without changing the View.
EDIT:
Some highly upvoted answers [1][2][3] support my in my thinking that it's really okay to bind directly to the Model.
It all comes down to code separation and reusability. Ideally, the View should be completely separated from the Model. If the View doesn’t rely on a specific implementation of the Model, then it can be reused with a different model to present some other data.
So, suppose you have a AlbumView and your current Model is Album, but in future you have decided to also add Movie or Book to you library. you could still use the same AlbumViewo display your movie and book objects. Furthermore, if you want to create a new project that has something to do with albums, you could simply reuse your Album class, because it’s not dependent on any view. That’s the strength of MVVM or MVC.
So for me, I would say, that your colleague is right, because Model naturally reflect the Data Access Layer Entity, where it will be stored and handled. In addition to that, Model may have more properties related to Access data layer such as created indexing. While you ViewModel is only related to the view and the presentation logic of your application. It only reflect what the user is going to see.
I would say using an ObservableCollection in the Model layer is wrong. By adding that you are basically saying "Model object stores data and notifies when it changes".
The role of the ViewModel is to manipulate the Model and provide an interface to the View for presenting the Model.
I believe your colleague is right because he is enforcing separation of concerns such that manipulating the Model should not impact the View.
I've been reviewing examples on the web of 3 layer design and I've noticed that most samples return either datasets or data tables. The thing that is confusing me is what if you would rather return a generic list of type so you can utlize properties or methods from within the type your list is based on? As example using a Name property that concats various fields in a specific way depending on the data, if the List is bound to a control on a form then the Name property can be used as the datafield. If you would want to accomplish the same thing when using a dataset or table, you'd have to return the data from the database to acheive the same (I try not to use datasets or datatables so I'm probably very wrong about this statement. :) )
The part that is really confusing me is about resusing code, to me it seems the only way to reuse code is to retrieve the data into either a dataset or datatable and then loop through the data and add it to a List, is this generally the best practice for 3 layer or is there a way to do this without datasets and datatables.
The example in the link below demonstrates in essence using datasets or tables and then adding it to an object but I'm forced to ask if this is the best practice?
http://www.codeproject.com/Articles/36847/Three-Layer-Architecture-in-C-NET
Thanks
Using DataTables is a specific dotnetism. The reason behind it is that they contain metadata about the structure of the data, which lets DataGrid (and other such components) display the data automatically without using reflection or so. My guess is this is amongst other things a heritage of the MS Access approach to RAD, where the intent was enabling "business people" to create apps by generating the user interface directly from a SQL schema, essentially doing the opposite of a tiered design. This heritage then seems to have leaked into the hivemind.
There's nothing wrong about using "plain" data structures, as long as you're willing to give up the RAD features, and the trend lately seems to have been to get rid of this tradeoff too. (For instance with Web Forms' strongly typed data controls, and MVC's model binding features.)
Also, speaking more generally, Code Project articles from before MVC was established are not really a good source of wisdom on general software architecture.
What you should carry your data on depends entirely on your needs.
If you retrieve data from the DB and bind it to a datagrid, datasets might give you the perfect solution. If you want some other method where data tracks its own update status you should look into Entity Framework. If you retrieve data and send it through a web service for cross platform or cross domain processing you need to load your data onto some other serializable classes of your own.
Take a look at the article below. It is a little old and targeted at EF4 but it summerizes pros and cons of different strategies very well. (There are three articles in the series, I suggest you read them all)
http://msdn.microsoft.com/en-us/magazine/ee335715.aspx
I think the samples you're finding used data tables and datasets because it's a simple way to show 3-tier design. Now days Entity Framework has largely replaced the "data access layer" mentioned in the sample.
Before entity framework when I wrote a data access layer I would return a generic list that I built from the database. To run an update, delete, or insert I would pass an object in as the parameter to the methods, then use the object's properties as the values in the sql statement. I preferred doing it that way for the reasons you mentioned but also because it allowed me to change the object definitions or db schema (or even use a different db all together) independently of each other.
I need to understand the best practices of MVC architecture implementation. I'm a Java and C# programmer. I know the basic of MVC. But i'm sorta confused on how to implement it. I know how to make a simple MVC based calculator. But here's the thing.
I wanted to make a simple database editor application using MVC. Should I construct a model and controller for every rows (objects) of the table? If so, how about the view of every objects? How do i handle them being deleted, updated, and inserted. And should I make the model and controller for the editor which is also a view?
If you don't want to use the Java Persistence API, consider using a Class Literals as Runtime-Type Token in your TableModel.
At first, if you are comfortable with Java try the Spring MVC. There are a lot of tutorial regarding this. If you are much more confident in C# try ASP .NET MVC 3. I will prefer the later one as in this case you have to deal with less configuration.
Now I will answer your question one by one.
At first create a model for every table in your database. Actually these models (which are nothing but classes) when instantiated are nothing but an individual row of the respective table. Your ORM (object relational mapping) tool (For java you can use hibernate, for c#.net you can use entity framework) will provide you specific methods (save(object), add(object), delete(object)) for updating the database
Now each controller should work with a specific model (Here I am ignoring the complexities of using multiple models.). But it may generate numerous views. By clicking a link in your view page you actually invoke the related method in the controller. The controller than binds the Data (if any) with the specific view realted to that link and then the view is rendered. So for deleting a row there should be a method named delete() (you may name it anything you want, so dont be confused) in your controller. When you want to delete a row invoke that method and inside the method remove that row by using something like delete(object) (these methods will be provided by your ORM) and then return another view. The same thing is applied for adding and updating data. But each method may generate different views. Its upto you that which view you return in each of these methods.
I hope the answer helps you. Cheers !!!
Should i consider ASP.NET MVC ViewModels only containing flat and primitypes types or it should contains complex Core/Domain model types ?
I'm looking for best practices.
Thanks.
Do what makes sense.
There are no authoritative sources that will tell you that using ViewModel with primitive types is going to kill kittens, because they would be wrong. And for every expert out there who tells you that using ViewData with magic strings is perfectly OK, there will be purists out there who will tell you that strongly-typed objects are the only way to go.
I write applications that read from a database and display data in a web page. I have tried it both ways (using ViewData and using a ViewModel object), and I am happiest when I have a ViewModel object to project into the web page. The ViewModel class is a place to encapsulate things like validation and view logic, if I need them, and it provides the data structure and strong typing that I like.
If I just want to display a record from one of my Linq to SQL classes, and I don't need extras such as dropdown data lists, I might use the Linq to SQL object directly. But if I do have extras, I put everything into a ViewModel class, and project that ViewModel instance (or an IEnumerable or IQueryable of them) into the view.
So I seldom use ViewData, but that's just my style. It's nice to know that it's still there if I need it.