MVVM explanation (Model, View, View Model)

Firstly, Let me start by stating that I am no .net expert, or even a solid 
intermediate, but in the spirit of helping some of us olde dogs learn some 
new .net tricks...

Here is the only article I've read (so far) that finally made things click.
http://jesseliberty.com/2010/05/08/mvvm-its-not-kool-aid-3/#viewSource

If you are new to C# and .net, think of the references to binding in the 
above article like dw.ShareData() only way more powerful.  Think of what you 
could do in pb if you could fill a text box, list box, radio button etc, by 
simply saying dw_Data.ShareData(st_Textbox.Text) and you'll start to get the 
idea.  Over simplfied of course but you have to start somewhere.

By the way the MVVM accronym seems backwards to me.  It should be... Model 
then ViewModel then View or M.VM.V.  I think it is expressed as MVVM (Model, 
View, ViewModel) due to the fact that the last ViewModel is the newest part 
added to the older pattern of View Model (MV) or as you may know it Visual 
Layer and Business Object Layer.  Think of the View (Visual layer) as you 
know it now, but separate the Model (Business Object Layer) into 2 parts. 
Part 1 is the code that acts on the data (complex processing, data creation, 
report generation, etc) and is called the ViewModel.  Part 2 is the 
reference to the data itself and is called the Model.  In Pb land we tend to 
think of the model in terms of datawindows because that is the object that 
we use most to directly interact with the data (which is almost always in 
some form of database).  In .net the model is literally any custom class 
that pulls "data" from anywhere.  The Model could be represent a webservice, 
text file, xml, database, or anything you want it to be, as long as it is 
the endpoint for your data as far as your program is concerned.  The benefit 
to all this, is that the model endpoint could change (table definition, 
database vendor, lose the database and go to an Amazon webservice, etc) and 
only 1 area needs attention.  Your complex processing code in the ViewModel 
is not affected in any way.  It calls the same objects and retrieves, 
updates, and deletes the results in the same format as before.  Now throw 
some automated unit testing in there (which is readily available in .net) 
and we might get to a point where a simple table change doesn't break old 
code or if it does the error is at least caught before the software is 
released or even user tested.

Why even care about MVVM you ask?  Mostly because WPF and Siverlight were 
designed and implemented in MVVM's image.  So, it seems to me not 
understanding MVVM will be like swimming against the current going forward 
and if you are going to use pb.net, you are moving forward (regardless of 
your feelings on the subject).

I hope this helps, and if it does please pay it forward (all teachers are 
still students).

Kevin Lindsay 

0
Kevin
7/29/2010 1:50:12 PM
sybase.powerbuilder.net 284 articles. 0 followers. Follow

13 Replies
1239 Views

Similar Articles

[PageSpeed] 51
Get it on Google Play
Get it on Apple App Store

Nice explanation. Good to see some general architectural discussion.

What you refer to as "Model" objects can be true Domain objects. That is, 
they can not only have methods that return "data", but can also have methods 
that act upon that data as well. For instance, if a business has complex 
pricing rules, calculating the total due for an order can take a lot of 
code. If you have an Order object that contains a Customer object and list 
of Line Item objects, you can encapsulate all of the logic for calculating 
the amount due in the Order object. Then the ViewModel object can get the 
amount due from the Order object as easily as it can get the OrderId. You 
could choose to put this logic in the ViewModel, having it retrieve the 
customer and all of the line items and applying all of the rules to finally 
pass the result to the View, but you might well want different ViewModels 
for different applications and client types. A real value of using Domain 
objects is that you can reuse business logic across different ViewModels - 
even ones for supporting applications or view technologies that you haven't 
thought of yet. The same logic for calculating amount due can be accessed by 
a billing clerk using a desktop app as a customer in a browser or an 
automated voice system. The ViewModel is not only decoupled from the actual 
data source, but it can be decoupled from core business logic as well.

Things like Hibernate and Entity Framework were created to supply the 
plumbing to get the data back and forth between Domain objects and actual 
data stores.

Not sure how any of this applies to PB, however. I don't see how datawindows 
fit in. How would someone go about implementing this kind of architecture 
using PB, and why?


"Kevin Lindsay" <klindsay@ivision.ca> wrote in message 
news:4c518714$1@forums-1-dub...
> Firstly, Let me start by stating that I am no .net expert, or even a solid 
> intermediate, but in the spirit of helping some of us olde dogs learn some 
> new .net tricks...
>
> Here is the only article I've read (so far) that finally made things 
> click.
> http://jesseliberty.com/2010/05/08/mvvm-its-not-kool-aid-3/#viewSource
>
> If you are new to C# and .net, think of the references to binding in the 
> above article like dw.ShareData() only way more powerful.  Think of what 
> you could do in pb if you could fill a text box, list box, radio button 
> etc, by simply saying dw_Data.ShareData(st_Textbox.Text) and you'll start 
> to get the idea.  Over simplfied of course but you have to start 
> somewhere.
>
> By the way the MVVM accronym seems backwards to me.  It should be... Model 
> then ViewModel then View or M.VM.V.  I think it is expressed as MVVM 
> (Model, View, ViewModel) due to the fact that the last ViewModel is the 
> newest part added to the older pattern of View Model (MV) or as you may 
> know it Visual Layer and Business Object Layer.  Think of the View (Visual 
> layer) as you know it now, but separate the Model (Business Object Layer) 
> into 2 parts. Part 1 is the code that acts on the data (complex 
> processing, data creation, report generation, etc) and is called the 
> ViewModel.  Part 2 is the reference to the data itself and is called the 
> Model.  In Pb land we tend to think of the model in terms of datawindows 
> because that is the object that we use most to directly interact with the 
> data (which is almost always in some form of database).  In .net the model 
> is literally any custom class that pulls "data" from anywhere.  The Model 
> could be represent a webservice, text file, xml, database, or anything you 
> want it to be, as long as it is the endpoint for your data as far as your 
> program is concerned.  The benefit to all this, is that the model endpoint 
> could change (table definition, database vendor, lose the database and go 
> to an Amazon webservice, etc) and only 1 area needs attention.  Your 
> complex processing code in the ViewModel is not affected in any way.  It 
> calls the same objects and retrieves, updates, and deletes the results in 
> the same format as before.  Now throw some automated unit testing in there 
> (which is readily available in .net) and we might get to a point where a 
> simple table change doesn't break old code or if it does the error is at 
> least caught before the software is released or even user tested.
>
> Why even care about MVVM you ask?  Mostly because WPF and Siverlight were 
> designed and implemented in MVVM's image.  So, it seems to me not 
> understanding MVVM will be like swimming against the current going forward 
> and if you are going to use pb.net, you are moving forward (regardless of 
> your feelings on the subject).
>
> I hope this helps, and if it does please pay it forward (all teachers are 
> still students).
>
> Kevin Lindsay 


0
Mark
8/1/2010 5:10:16 PM
Just for the sake of a good debate (because you know I can't resist one...), 
here's a counterpoint:
http://davybrion.com/blog/2010/07/the-mvvm-pattern-is-highly-overrated/

-- 
Paul Horan[Sybase]
http://paulhoran.ulitzer.com

"Kevin Lindsay" <klindsay@ivision.ca> wrote in message 
news:4c518714$1@forums-1-dub...
> Firstly, Let me start by stating that I am no .net expert, or even a solid 
> intermediate, but in the spirit of helping some of us olde dogs learn some 
> new .net tricks...
>
> Here is the only article I've read (so far) that finally made things 
> click.
> http://jesseliberty.com/2010/05/08/mvvm-its-not-kool-aid-3/#viewSource
>
> If you are new to C# and .net, think of the references to binding in the 
> above article like dw.ShareData() only way more powerful.  Think of what 
> you could do in pb if you could fill a text box, list box, radio button 
> etc, by simply saying dw_Data.ShareData(st_Textbox.Text) and you'll start 
> to get the idea.  Over simplfied of course but you have to start 
> somewhere.
>
> By the way the MVVM accronym seems backwards to me.  It should be... Model 
> then ViewModel then View or M.VM.V.  I think it is expressed as MVVM 
> (Model, View, ViewModel) due to the fact that the last ViewModel is the 
> newest part added to the older pattern of View Model (MV) or as you may 
> know it Visual Layer and Business Object Layer.  Think of the View (Visual 
> layer) as you know it now, but separate the Model (Business Object Layer) 
> into 2 parts. Part 1 is the code that acts on the data (complex 
> processing, data creation, report generation, etc) and is called the 
> ViewModel.  Part 2 is the reference to the data itself and is called the 
> Model.  In Pb land we tend to think of the model in terms of datawindows 
> because that is the object that we use most to directly interact with the 
> data (which is almost always in some form of database).  In .net the model 
> is literally any custom class that pulls "data" from anywhere.  The Model 
> could be represent a webservice, text file, xml, database, or anything you 
> want it to be, as long as it is the endpoint for your data as far as your 
> program is concerned.  The benefit to all this, is that the model endpoint 
> could change (table definition, database vendor, lose the database and go 
> to an Amazon webservice, etc) and only 1 area needs attention.  Your 
> complex processing code in the ViewModel is not affected in any way.  It 
> calls the same objects and retrieves, updates, and deletes the results in 
> the same format as before.  Now throw some automated unit testing in there 
> (which is readily available in .net) and we might get to a point where a 
> simple table change doesn't break old code or if it does the error is at 
> least caught before the software is released or even user tested.
>
> Why even care about MVVM you ask?  Mostly because WPF and Siverlight were 
> designed and implemented in MVVM's image.  So, it seems to me not 
> understanding MVVM will be like swimming against the current going forward 
> and if you are going to use pb.net, you are moving forward (regardless of 
> your feelings on the subject).
>
> I hope this helps, and if it does please pay it forward (all teachers are 
> still students).
>
> Kevin Lindsay 


0
Paul
8/2/2010 12:47:50 PM
Hi Mark,
Comments inline

> Nice explanation. Good to see some general architectural discussion.
Well I fugure so many of us are probably in the same (slow) boat 
architecture wise that I'm hoping we can teach each other a few things as we 
figure them out.

> What you refer to as "Model" objects can be true Domain objects. That is, 
> they can not only have methods that return "data", but can also have 
> methods that act upon that data as well. For instance, if a business has 
> complex

Ok I get that and have started to force myself to think of the model as 
almost a separate program all together with a defined api (almost like a 
database on it's own).  The old black box of data idea, I don't care how you 
get me this info (or how many places you had to look to find it) just get 
what I ask for.  My tendancy seems to be to place too much logic in the 
ViewModel leaving the model a bit empty, so I'll have to watch that.

>  A real value of using Domain objects is that you can reuse business logic 
> across different ViewModels - even ones for supporting applications or 
> view technologies that you haven't thought of yet. The same logic for 
> calculating amount due can be accessed by a billing clerk using a desktop 
> app as a customer in a browser or an automated voice system. The ViewModel 
> is not only decoupled from the actual data source, but it can be decoupled 
> from core business logic as well.

I was thinking in this situation you could just reuse the ViewModel with a 
different front end View?  In practise does the View and ViewModel end up 
more tightly coupled than I thought making this largely impossible?

> Not sure how any of this applies to PB, however. I don't see how 
> datawindows fit in. How would someone go about implementing this kind of 
> architecture using PB, and why?
Ah the million $ question.  I keep seeing PB in the model space\domain.  It 
deals with data well, so I keep thinking that is the logical place for it to 
fit in.  If I use the dw to handle all interaction with the backend 
database, WCF service, etc  then use it for a ViewModel that binds to the 
model in the standard .net method.  So in the end (rightly or wrongly) I'm 
not trying to create an end to end solution in PB I just want to use PB for 
what PB is good at.  I haven't tried this yet, so any thoughts on this are 
appreciated.

Kevin Lindsay 

0
Kevin
8/2/2010 2:49:17 PM
Hi Paul,

I believe, if you are not prepared to argue, you are not prepared to learn 
anything new.



Interesting article, but it seems, like more of the same MVVM but I might be 
far to newbie to grasp that discussion completely.  It seems (to me) he 
splits the ModelView into 2 pieces, but he then thinks of the Model as a 
black box beyond is immediate control. "In most Silverlight applications, 
the Model will be a Service Layer" I get what his is saying (I think) but to 
me he seems to be just treating his service layer like a database he didn't 
write (like a separate application all togther he might not have the actual 
code for).  All of his service proxies, he wants to create a new layer for, 
are really behaving like a more traditional model to a back end database 
(just replace my iAnywhere database with his service layer).  If you have a 
service layer that is public to potentially many different applications, I 
really think you are asking for trouble by considering that service layer a 
part of your current application.  Why create and expose a service layer at 
all (I assume he means web services of some flavour) if you never reasonably 
expect the service to be called outside of 1 application?  My point is that 
if you cannot (or will not) include your service layer into your singular 
applications design then it is not your Model for this application.  I know 
you want to promote reuse of the Model and ViewModel but in the end you have 
the 1 application you are working on and your MVVM for that 1 application is 
a snapshot of the resources used to make that application a reality.

Like I said before though, maybe I'm just thinking too small to grasp his 
point accurately or possibly at all.



Kevin Lindsay

0
Kevin
8/2/2010 3:29:16 PM
In article <4c56daed$1@forums-1-dub>, klindsay@ivision.ca says...
> I was thinking in this situation you could just reuse the ViewModel with a 
> different front end View?  In practise does the View and ViewModel end up 
> more tightly coupled than I thought making this largely impossible?

In some cases, you might be able to reuse a ViewModel. But not always. 
If you had a stateful C/S app, a stateless web app and a voice response 
system that all access Orders, it seems likeley that you would want 
different Objects to serve as ViewModels. A few years ago, we moved from 
using Struts to using JSF for our web applications. Different 
technologies with different ways of connecting to views. But we were 
able to re-use the same business objects and data access, which is 
managed using Hibernate.

> > Not sure how any of this applies to PB, however. I don't see how 
> > datawindows fit in. How would someone go about implementing this kind of 
> > architecture using PB, and why?
> Ah the million $ question.  I keep seeing PB in the model space\domain.  It 
> deals with data well, so I keep thinking that is the logical place for it to 
> fit in.  If I use the dw to handle all interaction with the backend 
> database, WCF service, etc  then use it for a ViewModel that binds to the 
> model in the standard .net method.  So in the end (rightly or wrongly) I'm 
> not trying to create an end to end solution in PB I just want to use PB for 
> what PB is good at.  I haven't tried this yet, so any thoughts on this are 
> appreciated.

Datawindows have a tight coupling to the underlying data source. If a 
table or column name changes, you've got to change every datawindow that 
uses the changed table or column. You can't develop or test your 
application without a database connection. And datawindows give you 
access to data - not true objects with business methods. A number of 
people have identified an anti-pattern called "Anemic Domain Model". Do 
a Google search on the term and you will find many references. I don't 
see how the datawindow can be of any help to get you beyond this.
0
Mark
8/2/2010 7:21:25 PM
We need someone who is very good at PB and also has a good grasp of C# 
design patterns to come up with a good example app for the rest of us to 
learn from.

"Paul Horan[Sybase]" <phoran_remove@remove_sybase.com> wrote in message 
news:4c56be76$1@forums-1-dub...
> Just for the sake of a good debate (because you know I can't resist 
> one...), here's a counterpoint:
> http://davybrion.com/blog/2010/07/the-mvvm-pattern-is-highly-overrated/
>
> -- 
> Paul Horan[Sybase]
> http://paulhoran.ulitzer.com
>
> "Kevin Lindsay" <klindsay@ivision.ca> wrote in message 
> news:4c518714$1@forums-1-dub...
>> Firstly, Let me start by stating that I am no .net expert, or even a 
>> solid intermediate, but in the spirit of helping some of us olde dogs 
>> learn some new .net tricks...
>>
>> Here is the only article I've read (so far) that finally made things 
>> click.
>> http://jesseliberty.com/2010/05/08/mvvm-its-not-kool-aid-3/#viewSource
>>
>> If you are new to C# and .net, think of the references to binding in the 
>> above article like dw.ShareData() only way more powerful.  Think of what 
>> you could do in pb if you could fill a text box, list box, radio button 
>> etc, by simply saying dw_Data.ShareData(st_Textbox.Text) and you'll start 
>> to get the idea.  Over simplfied of course but you have to start 
>> somewhere.
>>
>> By the way the MVVM accronym seems backwards to me.  It should be... 
>> Model then ViewModel then View or M.VM.V.  I think it is expressed as 
>> MVVM (Model, View, ViewModel) due to the fact that the last ViewModel is 
>> the newest part added to the older pattern of View Model (MV) or as you 
>> may know it Visual Layer and Business Object Layer.  Think of the View 
>> (Visual layer) as you know it now, but separate the Model (Business 
>> Object Layer) into 2 parts. Part 1 is the code that acts on the data 
>> (complex processing, data creation, report generation, etc) and is called 
>> the ViewModel.  Part 2 is the reference to the data itself and is called 
>> the Model.  In Pb land we tend to think of the model in terms of 
>> datawindows because that is the object that we use most to directly 
>> interact with the data (which is almost always in some form of database). 
>> In .net the model is literally any custom class that pulls "data" from 
>> anywhere.  The Model could be represent a webservice, text file, xml, 
>> database, or anything you want it to be, as long as it is the endpoint 
>> for your data as far as your program is concerned.  The benefit to all 
>> this, is that the model endpoint could change (table definition, database 
>> vendor, lose the database and go to an Amazon webservice, etc) and only 1 
>> area needs attention.  Your complex processing code in the ViewModel is 
>> not affected in any way.  It calls the same objects and retrieves, 
>> updates, and deletes the results in the same format as before.  Now throw 
>> some automated unit testing in there (which is readily available in .net) 
>> and we might get to a point where a simple table change doesn't break old 
>> code or if it does the error is at least caught before the software is 
>> released or even user tested.
>>
>> Why even care about MVVM you ask?  Mostly because WPF and Siverlight were 
>> designed and implemented in MVVM's image.  So, it seems to me not 
>> understanding MVVM will be like swimming against the current going 
>> forward and if you are going to use pb.net, you are moving forward 
>> (regardless of your feelings on the subject).
>>
>> I hope this helps, and if it does please pay it forward (all teachers are 
>> still students).
>>
>> Kevin Lindsay
>
> 


0
Roland
8/2/2010 7:41:38 PM
"Mark Maslow" <mark.maslow@sierraclub.org> wrote in message 
news:MPG.26c0ba7a685b8fcf98971e@forums.sybase.com...
> In article <4c56daed$1@forums-1-dub>, klindsay@ivision.ca says...
> In some cases, you might be able to reuse a ViewModel. But not always.
> If you had a stateful C/S app, a stateless web app and a voice response
> system that all access Orders, it seems likeley that you would want
> different Objects to serve as ViewModels. A few years ago, we moved from
> using Struts to using JSF for our web applications. Different
> technologies with different ways of connecting to views. But we were
> able to re-use the same business objects and data access, which is
> managed using Hibernate.

Ok that makes perfect sense, I hadn't thought of it like that.

> Datawindows have a tight coupling to the underlying data source. If a
> table or column name changes, you've got to change every datawindow that
> uses the changed table or column. You can't develop or test your
> application without a database connection. And datawindows give you
> access to data - not true objects with business methods. A number of
> people have identified an anti-pattern called "Anemic Domain Model". Do
> a Google search on the term and you will find many references. I don't
> see how the datawindow can be of any help to get you beyond this.

But every model is ultimately coupled to it's data source right?  I can't 
think of a situation where the backend data store could change significantly 
without the model (hopefully model only) having to be modified to reflect 
the change.  If database column is removed from a table that had validation 
logic associated with it in the model, the model will have to be refactored 
as well.  I can understand how the model could target a different data store 
(i.e. a webservice, or cloud database) without significant refactoring but a 
structure change will always cause some work right?
As far as PB goes, I'm thinking of the Model being coded in PB.net where 
each (not sure of the term here) "data structure" is actually a Pb.net 
assembly with 1 or multiple datastores\datawindows.  So the Customer model 
would have attributes (FirstName, Last Name, etc) to be exposed to the 
ViewModel, code for data validation, and a datawindow to handle database 
interaction and sorting, caching, etc.  My test unit could populate the 
customer with test data if in test mode (saw something like this in the MVVM 
Light demos) to get around the database connection requirement (which would 
be kinda of cool now that I think of it, no more test only database).  I 
understand the datawindow can not be the model in itself but it could be the 
final abstration to the database right?  I could do this in .net proper with 
table adapters and datasets but I'm thinking the model is where I could 
leverage alot of my existing pb business objects, not to mention development 
speed (since I know Pb a hell of alot better than c# at the moment).  This 
idea of course is completely academic at the moment, so maybe PB can not 
currently provide what I'd need to make this happen and I just don't know it 
yet.

Kevin Lindsay 

0
Kevin
8/2/2010 8:16:04 PM
One place I worked used an NVO class inherited from DataStore to 
encapsulate business rules associated with a specific data view. For 
visual purposes, a DW could share the data and that option was built 
into the base DW control ancestor. These objects allowed reuse of the 
logic between the C/S and web parts of the application.

Report Bugs to Sybase:  http://case-express.sybase.com/cx/welcome.do
Product Enhancement Requests:
http://my.isug.com/cgi-bin/1/c/submit_enhancement

On 8/2/2010 3:21 PM, Mark Maslow wrote:
> In article<4c56daed$1@forums-1-dub>, klindsay@ivision.ca says...
>> I was thinking in this situation you could just reuse the ViewModel with a
>> different front end View?  In practise does the View and ViewModel end up
>> more tightly coupled than I thought making this largely impossible?
>
> In some cases, you might be able to reuse a ViewModel. But not always.
> If you had a stateful C/S app, a stateless web app and a voice response
> system that all access Orders, it seems likeley that you would want
> different Objects to serve as ViewModels. A few years ago, we moved from
> using Struts to using JSF for our web applications. Different
> technologies with different ways of connecting to views. But we were
> able to re-use the same business objects and data access, which is
> managed using Hibernate.
>
>>> Not sure how any of this applies to PB, however. I don't see how
>>> datawindows fit in. How would someone go about implementing this kind of
>>> architecture using PB, and why?
>> Ah the million $ question.  I keep seeing PB in the model space\domain.  It
>> deals with data well, so I keep thinking that is the logical place for it to
>> fit in.  If I use the dw to handle all interaction with the backend
>> database, WCF service, etc  then use it for a ViewModel that binds to the
>> model in the standard .net method.  So in the end (rightly or wrongly) I'm
>> not trying to create an end to end solution in PB I just want to use PB for
>> what PB is good at.  I haven't tried this yet, so any thoughts on this are
>> appreciated.
>
> Datawindows have a tight coupling to the underlying data source. If a
> table or column name changes, you've got to change every datawindow that
> uses the changed table or column. You can't develop or test your
> application without a database connection. And datawindows give you
> access to data - not true objects with business methods. A number of
> people have identified an anti-pattern called "Anemic Domain Model". Do
> a Google search on the term and you will find many references. I don't
> see how the datawindow can be of any help to get you beyond this.
0
Jerry
8/2/2010 8:18:18 PM
My practical experience with using Domain Models in applications is with 
Hibernate. With Hibernate, you specify a mapping between the Domain 
object properties and the tables and rows on the DB that hold the data 
to populate those properties. So if the name of something on the DB 
changes, all you have to do is change the mapping, which is in one 
single place.

If you're using datawindows, Hibernate (or similar frameworks, like 
Entity Framework, which appears to be becoming a standard for database 
applictions in .NET) are not available to you. It's certainly possible 
to "roll your own" - retrieve the Order table into one datastore, the 
Order Detail data into another datastore, and the Customer data into yet 
another, and then write code to populate an Order object that contains a 
Customer object and a collection of Order Detail objects. Then track 
changes and send the data back to the datastores and issue updates as 
appropriate. But that seems like a big step backwards to me, as opposed 
to using something like Hibernate, which does most of the work for you 
(after creating the mapping, just retrieve the Order by Id, and 
everything gets populated and tracked for you). Hibernate only works 
with relational databases, so it wouldn't be helpful if your datasource 
is a web service. However, web services themselves often return complex 
structures, in which case you don't need much in the way of mapping. 
AFAIK, datawindows don't support web services that return complex 
structures, such as the Order object of my example. 

Anyway, if using .NET patterns and best practices is considered 
desireable, we need to see examples of how to implement them in PB. At 
this point, I'm just not seeing any good way to get there, other than a 
lot of low-level programming. If you have to do that, what's the point? 
Best practices generally point to keeping layers separate, while 
datawindows seem to be about collapsing layers in the pursuit of "rapid 
appliction development". Once you go from working with "data" to working 
with objects, datawindows seem to me to be of very limited use.


In article <4c572784$1@forums-1-dub>, klindsay@ivision.ca says...
> 
> "Mark Maslow" <mark.maslow@sierraclub.org> wrote in message 
> news:MPG.26c0ba7a685b8fcf98971e@forums.sybase.com...
> > In article <4c56daed$1@forums-1-dub>, klindsay@ivision.ca says...
> > In some cases, you might be able to reuse a ViewModel. But not always.
> > If you had a stateful C/S app, a stateless web app and a voice response
> > system that all access Orders, it seems likeley that you would want
> > different Objects to serve as ViewModels. A few years ago, we moved from
> > using Struts to using JSF for our web applications. Different
> > technologies with different ways of connecting to views. But we were
> > able to re-use the same business objects and data access, which is
> > managed using Hibernate.
> 
> Ok that makes perfect sense, I hadn't thought of it like that.
> 
> > Datawindows have a tight coupling to the underlying data source. If a
> > table or column name changes, you've got to change every datawindow that
> > uses the changed table or column. You can't develop or test your
> > application without a database connection. And datawindows give you
> > access to data - not true objects with business methods. A number of
> > people have identified an anti-pattern called "Anemic Domain Model". Do
> > a Google search on the term and you will find many references. I don't
> > see how the datawindow can be of any help to get you beyond this.
> 
> But every model is ultimately coupled to it's data source right?  I can't 
> think of a situation where the backend data store could change significantly 
> without the model (hopefully model only) having to be modified to reflect 
> the change.  If database column is removed from a table that had validation 
> logic associated with it in the model, the model will have to be refactored 
> as well.  I can understand how the model could target a different data store 
> (i.e. a webservice, or cloud database) without significant refactoring but a 
> structure change will always cause some work right?
> As far as PB goes, I'm thinking of the Model being coded in PB.net where 
> each (not sure of the term here) "data structure" is actually a Pb.net 
> assembly with 1 or multiple datastores\datawindows.  So the Customer model 
> would have attributes (FirstName, Last Name, etc) to be exposed to the 
> ViewModel, code for data validation, and a datawindow to handle database 
> interaction and sorting, caching, etc.  My test unit could populate the 
> customer with test data if in test mode (saw something like this in the MVVM 
> Light demos) to get around the database connection requirement (which would 
> be kinda of cool now that I think of it, no more test only database).  I 
> understand the datawindow can not be the model in itself but it could be the 
> final abstration to the database right?  I could do this in .net proper with 
> table adapters and datasets but I'm thinking the model is where I could 
> leverage alot of my existing pb business objects, not to mention development 
> speed (since I know Pb a hell of alot better than c# at the moment).  This 
> idea of course is completely academic at the moment, so maybe PB can not 
> currently provide what I'd need to make this happen and I just don't know it 
> yet.
> 
0
Mark
8/2/2010 9:57:02 PM
"Mark Maslow" <mark.maslow@sierraclub.org> wrote in message 
news:MPG.26c0def1bb6a60de98971f@forums.sybase.com...
> Anyway, if using .NET patterns and best practices is considered
> desireable, we need to see examples of how to implement them in PB. At
> this point, I'm just not seeing any good way to get there, other than a
> lot of low-level programming. If you have to do that, what's the point?
> Best practices generally point to keeping layers separate, while
> datawindows seem to be about collapsing layers in the pursuit of "rapid
> appliction development". Once you go from working with "data" to working
> with objects, datawindows seem to me to be of very limited use.

I agree, but it seems at this point it will be up to the PB community at 
large to make that leap.  I'm going to "have a go" at it (deadlines 
permitting) but I'm not sure the end result will be anything anyone would 
want to replicate.
Thanks again Mark, I learned alot from this discussion.

Kevin Lindsay 

0
Kevin
8/3/2010 12:31:53 PM
"Jerry Siegel [TeamSybase]" <jNOsSPAMsiegel@yahoo.com> wrote in message 
news:4c57280a@forums-1-dub...
> One place I worked used an NVO class inherited from DataStore to 
> encapsulate business rules associated with a specific data view. For 
> visual purposes, a DW could share the data and that option was built into 
> the base DW control ancestor. These objects allowed reuse of the logic 
> between the C/S and web parts of the application.

That is roughly how my application has been structured.  Every table or data 
structure has it's own business object inherited from datastore (i.e. 
nv_Order, nv_OrderDetail, nv_Customer, etc).  Each business object has 
public functions to retrieve by certain key columns, add by structure or 
array of structures, delete, retrieve data as structure etc.  On the visual 
side I can sharedata to a datawidow control or just use the business object 
as a data cache and handle the display, update, or delete manually in the 
background.  It definitely takes longer to code, but the benifits have been 
great when dealing with code changes, database changes etc.  I guess that is 
why I keep thinking the Model level of MVVM is pretty much what I have been 
doing in PB for the last 5+ years.  My current visual level or view level is 
what would get split into a View and a View Model.  I haven't had much use 
for reuse around here but that is about to change, which is why I'm trying 
to figure out where I can use my code in a .net world.

Kevin Lindsay 

0
Kevin
8/3/2010 12:44:04 PM
Here's a nice video that illustrates the advantages of MVVM as a WPF 
design patter.  It also shows a simple UI in action.
http://channel9.msdn.com/shows/Continuum/MVVM/

In my 'spare' time I'm working on a lite weight PB example that shows 
all the moving parts.  I think MVVM will be a great mechanism for 
replacing the WinForm kind of things we do (controls on a window)

However, as has been so well noted in this discussion, DataWindow 
Technology being so self contained and having its own tight coupling 
between the presentation layer, the data buffer and the resultset 
stands apart from the databinding and template mechanism so essential to 
WPF and XAML.  My current thinking says why "Follow the Jones'? " to 
break apart or overly complicate the beautiful mechanism already in 
place.  My current thinking says use Sharedata( ) between the GUI to a 
NVO datastore that can be extended with new methods to support unit 
testing them in the way that a MV is designed.  Use a redirect mechanism 
ala pfc_u_dw to route to the MV ds control so that the UI remains 
unpolluted.

So in this way of thinking the Expression Blend person will also have to 
learn how to design DataWindow Objects (at least we can be kind and give 
them the sp calls or query objects to hide the db from them)

my 2�
Yakov



On 8/2/2010 3:41 PM, Roland Smith [TeamSybase] wrote:
> We need someone who is very good at PB and also has a good grasp of C#
> design patterns to come up with a good example app for the rest of us to
> learn from.
>
> "Paul Horan[Sybase]"<phoran_remove@remove_sybase.com>  wrote in message
> news:4c56be76$1@forums-1-dub...
>> Just for the sake of a good debate (because you know I can't resist
>> one...), here's a counterpoint:
>> http://davybrion.com/blog/2010/07/the-mvvm-pattern-is-highly-overrated/
>>
>> --
>> Paul Horan[Sybase]
>> http://paulhoran.ulitzer.com
>>
>> "Kevin Lindsay"<klindsay@ivision.ca>  wrote in message
>> news:4c518714$1@forums-1-dub...
>>> Firstly, Let me start by stating that I am no .net expert, or even a
>>> solid intermediate, but in the spirit of helping some of us olde dogs
>>> learn some new .net tricks...
>>>
>>> Here is the only article I've read (so far) that finally made things
>>> click.
>>> http://jesseliberty.com/2010/05/08/mvvm-its-not-kool-aid-3/#viewSource
>>>
>>> If you are new to C# and .net, think of the references to binding in the
>>> above article like dw.ShareData() only way more powerful.  Think of what
>>> you could do in pb if you could fill a text box, list box, radio button
>>> etc, by simply saying dw_Data.ShareData(st_Textbox.Text) and you'll start
>>> to get the idea.  Over simplfied of course but you have to start
>>> somewhere.
>>>
>>> By the way the MVVM accronym seems backwards to me.  It should be...
>>> Model then ViewModel then View or M.VM.V.  I think it is expressed as
>>> MVVM (Model, View, ViewModel) due to the fact that the last ViewModel is
>>> the newest part added to the older pattern of View Model (MV) or as you
>>> may know it Visual Layer and Business Object Layer.  Think of the View
>>> (Visual layer) as you know it now, but separate the Model (Business
>>> Object Layer) into 2 parts. Part 1 is the code that acts on the data
>>> (complex processing, data creation, report generation, etc) and is called
>>> the ViewModel.  Part 2 is the reference to the data itself and is called
>>> the Model.  In Pb land we tend to think of the model in terms of
>>> datawindows because that is the object that we use most to directly
>>> interact with the data (which is almost always in some form of database).
>>> In .net the model is literally any custom class that pulls "data" from
>>> anywhere.  The Model could be represent a webservice, text file, xml,
>>> database, or anything you want it to be, as long as it is the endpoint
>>> for your data as far as your program is concerned.  The benefit to all
>>> this, is that the model endpoint could change (table definition, database
>>> vendor, lose the database and go to an Amazon webservice, etc) and only 1
>>> area needs attention.  Your complex processing code in the ViewModel is
>>> not affected in any way.  It calls the same objects and retrieves,
>>> updates, and deletes the results in the same format as before.  Now throw
>>> some automated unit testing in there (which is readily available in .net)
>>> and we might get to a point where a simple table change doesn't break old
>>> code or if it does the error is at least caught before the software is
>>> released or even user tested.
>>>
>>> Why even care about MVVM you ask?  Mostly because WPF and Siverlight were
>>> designed and implemented in MVVM's image.  So, it seems to me not
>>> understanding MVVM will be like swimming against the current going
>>> forward and if you are going to use pb.net, you are moving forward
>>> (regardless of your feelings on the subject).
>>>
>>> I hope this helps, and if it does please pay it forward (all teachers are
>>> still students).
>>>
>>> Kevin Lindsay
>>
>>
>
>

0
Yakov
8/30/2010 5:38:46 PM
In article <4c7beca6$1@forums-1-dub>, yakovwerde@optonline.net says...
> So in this way of thinking the Expression Blend person will also have to 
> learn how to design DataWindow Objects (at least we can be kind and give 
> them the sp calls or query objects to hide the db from them)
> 

Good luck with that strategy.

I ran into this limitation years ago when trying to get data into a 
public web site using PB. I'm not a graphic designer. There are other 
people on staff who are quite good at making pages look nice, but they 
don't know anything about datawindows. I needed to make the data 
available as data to be formatted by the web designers. That was the 
biggest single reason that I gave up years ago on using PB with any kind 
of web app.

Keeping presentation completely separate from data and business logic is 
not something I value in order to "follow the Jones'". It has very clear 
value in the real world, and the value is especially clear when you're 
using a markup language for presentation. The fact that datawindows 
"stand apart from the databinding and template mechanism so essential to 
WPF and XAML" seems to me to be a significant issue that cannot be 
simply or easily dismissed. It is apparently possible to create a PB app 
that is deployed via WPF, but I'm not at all convinced that it's 
possible to build a real WPF using PB.
0
Mark
8/30/2010 7:10:56 PM
Reply:

Similar Artilces:

Domain Model vs. View Model
I have my domain entities, for this example I'll use Order.  In my view I need to display certain properties of said Order.  With MVC, I'm assuming I create a OrderViewModel like so: public class OrderViewModel{ public DateTime OrderDate{get;set;} public decimal OrderValue{get;set;}}In my controller, I instantiate an OrderViewModel and populate with properties from my Order entity then return that to the View. My question is would I fit OrderViewModel to work for all my Views that need to display Order data?  Or do I create a Model for each View? If so, and I ha...

Model View Controller In PowerBuilder
C=f3mo puedo utilizar el m=f3delo MVC para crear paginas para los navegadores de los celulares inteligentes. Utilizando los webforms. How I can use the MVC model to create pages for browsers for smartphones. Using webforms. > C=f3mo puedo utilizar el m=f3delo MVC para crear paginas > para los navegadores de los celulares inteligentes. > Utilizando los webforms. Hi Kerlyn; MVC is an application architecture not a technology for smart phone web browser enablement. However, I use MVC in my EAServer / PB framework to build JSP or ASP driven web pages from Web DataW...

Model view
I accidentially added the "model view" to a project. How can I get rid of this again? I cannot find any option but it always wastes a lot of time when I open such a project! Istan Istan Velo wrote: > I accidentially added the "model view" to a project. How can I get > rid of this again? I cannot find any option but it always wastes a > lot of time when I open such a project! Istan Seach for section(s) with "model" in your project file (XML bds/cbporj) and remove them. -- Alex > {quote:title=Alex Belo wrote:}{quote} > Istan Velo ...

error while viewing view in .net
xp x64 OS sql any 10 .net provider asa 8.3 server trying to run a view with typed dataset with computed columns generate error. i will update the error message attachment in the next post. thanks vsv "vsv" <nospam@nospam.com> wrote in message news:46a7f128$1@forums-1-dub... > xp x64 OS > sql any 10 .net provider > asa 8.3 server > trying to run a view with typed dataset with computed columns generate > error. > i will update the error message attachment in the next post. > thanks > vsv > > begin 666 errorInSQLAnywh...

ASP.Net and MVC-DAO (Model View Control)
Hi all.I like to know how to implemente a complex architecture with design patterns MVC and DAO in ASP.Net (and VisualBasicNet for dll) I can think to write sql access inner ASPX pages. thank you. ...

Unable to access a model class like <%=ViewData.Model.AccountID %> in view pages
In ASP.NET MVC, when accessing a model class like <%=ViewData.Model.AccountID %> in view pages, getting the below error: CS0012: The type 'mvc.main.Model.User' is defined in an assembly that is not referenced. You must add a reference to assembly 'mvn.main', Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The web projects contains reference to the class library containing model class and added the below code in the ViewPage base class public partial class ViewUser : ViewPage { } Can any one guide me?Thanks in advance   Could be a...

Can "Add View..." ignore a property in my model when creating a strongly-typed view?
 I like the "Add View..." wizard, but I want VS to ignore a property in my model when making a strongly-typed view which automatically impletements the "Create" View Content.  For example, I use Azure Tables and therefore have a "PartitionKey" property as well as one called "TimeStamp".  When automatically creating a View, I don't want these properties displayed.  What's the best way to proceed? I don't want to manually edit the automatically generated View because I'm frequently deleting and creating this View ...

Weired problem with : GRID VIEW + DETAILS view in MODEL POPUP with BETA 1.0 RELEASE
Hi guys,i am having some weired problemi have a grid view when,when user click on the select button on the grid view i am  displaying the details in a details view using a modal popup extender.everything works nice.but if i am doing paging then also i am getting the details view popup in a modal pop   MY SAMPLE CODE  :  <asp:Panel Style='display: none;' ID='Popup' runat='server'>  <asp:UpdatePanel ID="UpdateList2" runat="server">         <contenttemplate>     &...

ASP.NET Application Model/ASP.NET Page Execution Model
Hi,At what point of ASP.NET Application Life Cycle does the Page Life Cycle kicks in when serving a .aspx page to the client? Is it after Application_ResolveRequestCache()? if it is so, does the page life cycle executes all the steps (page.init event, page.load event, validation of user input, event handling, automatic data binding and cleanup) immediately after Application_ResolveRequestCache() and then continues to carry on with remaining of Application Life Cycle Events?Thanks,Csharplearner~C#Learner*************************************************Please remember to Mark As Answ...

MVC (Model-View-Controller) based framework for Web .NET app. released
Hi all. I've worked in a MVC (Model-View-Controller) framework for Microsoft ..NET Web applications. The framework has now been released and is in Beta version. The framework is based on Model 2 from Sun Microsystems, hence very similar to Struts (actually it's inspired on Struts), a very successful Java framework. Though it's a lot simpler (doesn't have all Struts features). I'm looking for some comments, opinions, ideas, bugs, sugestions and critics. The project is supported by SourceForge and is available at http://sourceforge.net/projects/lattis/ or at http://lattis.sourceforg...

"Add View" Dialog doesn't show my models in the "View data class" drop down list.
My models are in a separate project which my MVC Web Application references.   When I go Add -> View, the "Add View" dialog does not contain any of my models.  It does however contain other classes from other referenced projects and libraries.  The MVC Web App compiles cleanly with no errors or warnings and my model types are visible to the controlers.What am I missing? dw Hi I'm following up on this. For now you should be able to work around this by typing the name of the model in the dialog. Jacques Hi Cyberfloatie, Do your models come from an assembl...

Model-View-Controller
There's a nice wiki to read "http://en.wikipedia.org/wiki/Model-view-controller" about MVC. Maybe this will help people understand. ...

Views from a migrated model
I have a Database model in Powerdesigner 8.0 which was migrated from version 6.0. During the migration all of my views were mangled. I am having serious problems trying to rebuild the views. There is some form of autoformat feature enabled that I cannot override which keeps killing my changes to the SQL syntax. Any help would be appreciated. Is there a way to disable this autocorrect feature? No only does PD mangle the view but if it is very big then it won't even compile on the database, because PD wraps lines that are greater than about 500 characters. When he wraps, it ...

Getting Model in the View
Hi I have created a class with name as Result which has Hashtable inside which I am going to store the Collections of my Models. When I try to assign the Collection to List<model> the intellisence is not showing my model class Name. If it is Code Behind I can include the namespace with Using clause, but how to do it in the aspx Page. Please help. Thanks Anandraj.A.  In your web.config, under <system.web>/<pages>/<namespaces> just add the reference to your desired namespace, for example: <add namespace="MyProject.Classes" />  M...

Web resources about - MVVM explanation (Model, View, View Model) - sybase.powerbuilder.net

Explanation - Wikipedia, the free encyclopedia
An explanation is a set of statements constructed to describe a set of facts which clarifies the causes , context , and consequences of those ...

An Explanation of Captchas - Facebook
Facebook Security hat eine Notiz mit dem Titel An Explanation of Captchas geschrieben. Du kannst den vollständigen Text hier lesen.

Facebook modifies proposed changes to terms of service, provides explanations in response to user feedback ...
Facebook today released a new set of proposed changes to its terms of service and offered more detailed explanation of its revisions based on ...

What is a good explanation of Latent Dirichlet Allocation?
Answer (1 of 2): Suppose you have the following set of sentences: * I ate a banana and spinach smoothie for breakfast * I like to eat broccoli ...

SAP HANA Certification and Interview Test Prep - Questions, Answers and Explanation on the App Store ...
Get SAP HANA Certification and Interview Test Prep - Questions, Answers and Explanation on the App Store. See screenshots and ratings, and read ...

The Higgs and a Jewish Wedding: An Explanation of the Higgs Field - YouTube
I use the behavior of people at a festive Jewish wedding to explain the action of the Higgs Fieldthe field that carries the action of the Higgs ...

It may not be Watergate but more explanation is needed
Within about 16 hours of James Ashby lodging his sexual harassment claim against Peter Slipper in April, Tony Abbott was dead certain of its ...

Stephen Roach Has A Rational Explanation For All Of China's Ghost Cities
China has received much flak for building “ghost cities” and “bridges to nowhere.” Recent reports show that construction in Ordos, the most famous ...

If you need a break, find a new explanation
If you are looking for the perfect excuse, look no further.

AFL grand final 2015: Billy Brownless calls mum a stripper, Sam Newman explanation - HeraldSun Search ...
SAM Newman has called on everyone to cut Billy Brownless some slack over sexist comments he made towards a mother and daughter.

Resources last updated: 11/22/2015 5:15:31 AM