MVP/MVC/Decoupled architecture VS modern databound controls
-
Hi.. Modern day application design seems to always lean towards a decoupled architecture: you have a dumb view, which is independent of your data model. This makes sense as it allows you to reuse the controller/model independently from the view. Seemingly contradicting this is modern controls which seem to lean more and more towards databound designs. How do we reconcile this kind of architecture with the controls at our disposal? For example, I am creating an application following a Passive View MVP architecture that, at some point, will have to manipulate items in a grid, and the grid works best if it is directly databound to the database. Am I using the wrong design architecture? Or should I be super-abstracting my data? (Database -> Dataset -> Classes -> Dataset -> View) :confused: Design patterns always sound so good in theory... :)
-
Hi.. Modern day application design seems to always lean towards a decoupled architecture: you have a dumb view, which is independent of your data model. This makes sense as it allows you to reuse the controller/model independently from the view. Seemingly contradicting this is modern controls which seem to lean more and more towards databound designs. How do we reconcile this kind of architecture with the controls at our disposal? For example, I am creating an application following a Passive View MVP architecture that, at some point, will have to manipulate items in a grid, and the grid works best if it is directly databound to the database. Am I using the wrong design architecture? Or should I be super-abstracting my data? (Database -> Dataset -> Classes -> Dataset -> View) :confused: Design patterns always sound so good in theory... :)
I don't know, and I'm interested in the replies you will get. I guess the fitting quote will be this one: In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
-
Hi.. Modern day application design seems to always lean towards a decoupled architecture: you have a dumb view, which is independent of your data model. This makes sense as it allows you to reuse the controller/model independently from the view. Seemingly contradicting this is modern controls which seem to lean more and more towards databound designs. How do we reconcile this kind of architecture with the controls at our disposal? For example, I am creating an application following a Passive View MVP architecture that, at some point, will have to manipulate items in a grid, and the grid works best if it is directly databound to the database. Am I using the wrong design architecture? Or should I be super-abstracting my data? (Database -> Dataset -> Classes -> Dataset -> View) :confused: Design patterns always sound so good in theory... :)
ruanr wrote:
should I be super-abstracting my data?
This is exactly what I recently found I needed to do using a MS TreeView and a STL-like Tree container. I set out wanting a series of low level instructions to be sequentially sent to a cell of electro/mechanical devices including a robot arm and other automated bits of laboratory kit. But wanted to give the User control of this instruction sequence by presenting them with simple control buttons much like those of a Video or DVD player: Forward, Pause, Step and Stop. But critically I also wanted to be able to undo/redo the instructions and add Back and Step-Back to those options presented to the User. I also wanted to be able to eventually throw away my development GUI and have someone then integrate what was left into a nice shiny Application GUI alongside all the other bells and whistles needed. I found a tree view was the 'natural' way to display to the User and the MS TreeView Control did this, but it didn't do other things I wanted so found another STL type Tree container class that I could use to accomplish the other things.
ruanr wrote:
Design patterns always sound so good in theory
I based each instruction to a device on a combination of Design Patterns: Command and Do/Undo so that a Do-instruction could be loaded into a Leaf (of the STL-type tree) with a corresponding Undo-instruction. Of course I had to link the corresponding nodes on the View tree to the Container tree but this wasn't that difficult. Though non-'super-abstraction' is tempting, separating the view from the the actual data like this I've found to be an essential development approach. From so many perspectives: Project-Management; Maintenance or Further-Development, separation like this turns one problem to two nicely defined smaller ones, reduces the overall complexity and makes the whole much cleaner, more likely to actually work and much more understandable to others.
-
Hi.. Modern day application design seems to always lean towards a decoupled architecture: you have a dumb view, which is independent of your data model. This makes sense as it allows you to reuse the controller/model independently from the view. Seemingly contradicting this is modern controls which seem to lean more and more towards databound designs. How do we reconcile this kind of architecture with the controls at our disposal? For example, I am creating an application following a Passive View MVP architecture that, at some point, will have to manipulate items in a grid, and the grid works best if it is directly databound to the database. Am I using the wrong design architecture? Or should I be super-abstracting my data? (Database -> Dataset -> Classes -> Dataset -> View) :confused: Design patterns always sound so good in theory... :)
ruanr wrote:
Am I using the wrong design architecture?
Only if you are overdesigning. It's ideal if you have a complex datasource, lots of developers, and/or lots of different ways of visualizing the data. If you're only displaying a list from Microsoft Access and asking the user to select an item therefrom; by all means, just databind it. As a question to you; what benefits do you gain from using an MVC/MVP pattern, and what benefits would you have without this design?
I are Troll :suss:
-
Hi.. Modern day application design seems to always lean towards a decoupled architecture: you have a dumb view, which is independent of your data model. This makes sense as it allows you to reuse the controller/model independently from the view. Seemingly contradicting this is modern controls which seem to lean more and more towards databound designs. How do we reconcile this kind of architecture with the controls at our disposal? For example, I am creating an application following a Passive View MVP architecture that, at some point, will have to manipulate items in a grid, and the grid works best if it is directly databound to the database. Am I using the wrong design architecture? Or should I be super-abstracting my data? (Database -> Dataset -> Classes -> Dataset -> View) :confused: Design patterns always sound so good in theory... :)
ruanr wrote:
at some point, will have to manipulate items in a grid
As I understand it, to perform tasks like manipulating items in a grid, we will be using constructs like Commands and Attached Behaviours (at least in WPF and Silverlight). However, I would be curious to know the best ways to do this in ASP.Net.
Me, I'm dishonest. And a dishonest man you can always trust to be dishonest.
Honestly. It's the honest ones you want to watch out for...modified on Sunday, March 28, 2010 11:43 AM
-
Hi.. Modern day application design seems to always lean towards a decoupled architecture: you have a dumb view, which is independent of your data model. This makes sense as it allows you to reuse the controller/model independently from the view. Seemingly contradicting this is modern controls which seem to lean more and more towards databound designs. How do we reconcile this kind of architecture with the controls at our disposal? For example, I am creating an application following a Passive View MVP architecture that, at some point, will have to manipulate items in a grid, and the grid works best if it is directly databound to the database. Am I using the wrong design architecture? Or should I be super-abstracting my data? (Database -> Dataset -> Classes -> Dataset -> View) :confused: Design patterns always sound so good in theory... :)
I think there are 2 distinct levels of understanding with data binding. The newbie uses the MS wizardy things and is led into the mire of controls bound directly to the dataset/table etc. This lasst until they actually want to do something beyond displaying an Access list for the user to select from, at which point the new dev finds a whole new universe of DAL, object layer, OOP and all the stuff a more seasoned developer already deals with. Then the learning really begins. IMHO tightly coupled controls have absolutely no place in anything but a learning/prototype application. MS is doing the newbie a great disservice even creating the wizardy things.
Never underestimate the power of human stupidity RAH