|
Kevin Marois wrote: I do MVVM apps all the time and I strt from scratch
Yeah but I bet you have a bunch of tools/utilities/styles etc. I know I have and you could almost call them a framework.
I started off with MVVM light but we kept extending the dammed thing with stuff we need specific to our style. Starting a new project is a bitch, you need to chase around and get all the really useful bits from the last project(s). We now have most of them in a single utilities project but it keeps changing!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
... because its awesome to have 50 copies of all your classes strewn across 100 projects and have all the different versions be different 6 months down the road rather then put it in a reusable library  .
I don't use any of the "popular" MVVM frameworks like MVVM light, Cinch, etc... but I do have a framework that I put together myself... c&p'ing code repeatedly is just silly.
|
|
|
|
|
SledgeHammer01 wrote: c&p'ing code repeatedly is just silly
I just wish I could put styles in a central, reusable project like I can with code.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Why can't you? I do this all the time. You basically create an assembly full of resource dictionaries.
|
|
|
|
|
So every time you write a new MVVM app, you write the following from scratch:
1) RelayCommand and RelayCommand<T>?
2) ViewModelBase?
3) a Messenger service to communicate between ViewModels?
4) a ViewLocator?
5) a dialog service?
Aside from the above obvious "required" stuff, you also usually need:
1) some way to map events to commands
2) a DI container
3) lots of other little things here and there... for example a way to bind to DialogResult, a way to bind to multi-select list controls, etc.
Thats just off the top of my head...
|
|
|
|
|
Have you read my series of articles? (See my sig for a link)
I didn't use a framework, just a couple of classes that make things easier, and the example as a whole is, I think, about as simple as it can get and still be real enough to be more than a trivial "Hello World"
It's WPF - but converting to Silverlight is pretty easy if you need to.
|
|
|
|
|
In 95% of projects MVVM adds another degree of complication that is simply not necessary. For what? To separate the UI from business logic? You are probably doing this anyway. For automated testing? I fail to see how automated testing can test anything but the simplest of scenarios.
Check the excellant tutorials on the Silverlight site to get started. Look into entity framework (EF) and Domain Services to generate code for backend database access. Use one of the business application templates to stub out a new project with styling. Avoid MVVM unless you are working on a team of dozens.
|
|
|
|
|
Glosse wrote: In 95% of projects
Did you know that 78% of statistics on the internet are just made up?
Glosse wrote: I fail to see how automated testing can test anything but the simplest of scenarios.
Then you're doing it wrong
Have you ever actually developed an MVVM project?
I rather tend to agree that there are many cases where MVVM would be overkill if you were just going to use it for a single small project. But if you develop using MVVM for everything, it becomes second nature, and you start thinking in MVVM terms. It is massively helpful in large teams, or when the gui design may change (i.e. you have customers) but there's no reason to avoid it in any size team (from 1 up) - at the very least, once you know the pattern and are familiar with your way of doing it, there's no disadvantage.
|
|
|
|
|
I'm on a 1 1/2 man team and have written WPF projects using both MVVM and non MVVM ways. The non MVVM projects are complete clusterf**ks in terms of code organization. Everything is hacked together with duct tape and chicken wire. I then developed my own MVVM framework (the right way) and wrote a few projects using it. The code is MUCH cleaner, MUCH more elegant, there are very few "cheezy hacks" and there is no duct tape and chicken wire holding things together. Thats the biggest advantage of MVVM IMO. The biggest PROBLEM IMO is getting a framework together that actually allows you to do MVVM properly. Theres much, much, much more to doing proper MVVM then just having a RelayCommand<T> implementation that you C&P everywhere. Once you've done a few MVVM projects (the right way) and have it all fleshed out, the next project is much easier since you've already solved all the typical MVVM problems and of course put it all together in a reusable framework.
|
|
|
|
|
I think that's what I said, isn't it?
The only reasons I wouldn't use MVVM (at least for silverlight/wpf) would be:
Pre-existing project where conversion isn't practical.
The Boss Told Me To Do It Another Way (aka the other devs don't understand)
I'd never done MVVM before, didn't have the framework bits and bobs I do have, and didn't foresee more than this one project
I think it's that third one that gets a lot of people. They think that they are just going to develop one thing in wpf, and it's a small one, so the overhead of getting to know WPF outweighs the benefits for this one project
Usually, I think, what happens is that this project grows into the sorry cheezy-hack state you describe, and other projects follow - each of which is met by the "it's too small to use MVVM"
The thing I personally like about MVVM is the way it enables me to change the way I think about the design of a project, without worrying too much about what it's really going to look like. Conversely, once the tech design is done, I can sit and play with the pretty stuff until it blows the socks off my customers, who generally do like shiny objects.
|
|
|
|
|
I took me about 4 months to get my MVVM framework from nothing to where its at now where it does everything I need. When I first saw MVVM, I thought, yeah, its overkill for a small app, so I avoided it like the plague. But thats simply because I didn't fully understand it yet. Thats the case with everyone who says "its not worth it in a small app"... they just haven't gotten it yet. At this point, I'd even write a Hello World app using MVVM because the code is so much cleaner.
|
|
|
|
|
I stand abashed. MVM was devised by people far smarter than me. However, coding trends come and go.
It would be interesting to do a survey to see how many are actually using the MVVM pattern, or are planning to use it. MVM seems to fly in the face of the KISS principle.
As a consultant, bidding and developing LOB apps is very competitive. Time is money. Code should be concise and logically structured. It should be easily picked up and modified at a later date.
What are the benefits? You say it is elegant. You say once you get used to it its easy. In the middle ages wearing a hair shirt or self flagelation were thought to bring you closer to God.
|
|
|
|
|
Well, sometimes I find people who over complicate stuff for no reason to be a bit pretentious and they are just trying to impress themselves. In the case of MVVM however, its just simply a better way to write WPF code. When I first saw it, I thought like you: "geez, this is stupid... its making things more complicated", but once I got used to it, I saw *WHY* its good.
For example, lets say you implement a dialog box that has a few buttons and a ListView, chances are you populate most if not all of the data in the constructor, manually insert stuff into the ListView, subscribe to lots of events, have a lot of duplicate code and tie all of the dialogs logic closely to the ListView. Now lets say your boss is a douche and comes to you in a month and says "I don't like the ListView, lets change it to a WidgetView". Well, now you pretty much need to re-write and re-test all your dialog code. Sux 2 b U. If you had written it in the MVVM style, you would have been able to swap out the ListView for a WidgetView in about 5 minutes and not have to re-write or re-test anything. You'd also have a lot less code, your dialog would come up faster because you would be lazy loading all your data (one of the things that MVVM kind of pushes indirectly) and you could write automated tests for your dialog box if thats something your company does.
Yes... its much easier to quickly whip out:
somecontrol.SomeEvent += <tab><tab>
vs. creating a RelayCommand and implementing its 2 event handlers, but you can pretty much write a macro for that in about 2 seconds. Theres already a built in macro for defining dependency properties, so adding one for the RelayCommand is just c&p pretty much.
The code does end up being more elegant, but the advantage for me is that I don't have to keep changing the dialog box code until the boss is happy with it, I just tweak some xaml.
|
|
|
|
|
Glosse wrote: MVM seems to fly in the face of the KISS principle.
The MVVM principal is actually reasonably simple. The problem, I think, with peple's taking up of it is that it isn't something you can just become an expert in in a couple of days - you need to have the time to play with it and get to know your way around - and decide how YOU want to do it.
It took me a few months from first reading about it to actually having something I felt comfortable enough to use in the real world. I still don't use it enough to make is second nature (because i can't use it in my current day job) but if I was starting a new project, and could, I would certainly use it.
Glosse wrote: MVM seems to fly in the face of the KISS principle.
There are a lot of articles out there showing people how to overcome difficulties using MVVM, or how to achieve something using MVVM that, I think, make it look far more complex than it is in fact.
many people misunderstand MVVM (the 'there must be not code behind' ers being a majority group!) Again, once you have been using it for a while, you start thinking about projects differently and it becomes 2nd nature.
Glosse wrote: What are the benefits?
In my experience, especially as a consultant, the user is never, ever, happy with the project they receive. it can do all the clever things that they never even thought of, technically it can be doing something in milliseconds that other systems take many seconds to do, and can have a small memory footprint, be self updating and extensible - but the customer doesn't like that shade of green, would like the fonts bigger, hates check boxes and wants radio buttons, and so on.
Designed with MVVM, the presentation can be changed, leaving the functionality alone. The application still does just what it used to , but now looks different.
Indeed, with the right set up, you can display design time data, and sit with the user to show them as you develop, without writing code (or, at least, not much)
Glosse wrote: In the middle ages wearing a hair shirt or self flagelation were thought to bring you closer to God.
I appreciate what you are saying - are the MVVM evangelists just that - evangelists who have faith and want to spread the word? Do they just 'believe'.
I can't speak for others, but my experience was to start with thinking "so what's so great about this MVVM thing" and start playing. I then went through the "well, this is crap, I can't even show a dialog box without thirty pages of code" stage. I nearly gave it up at that point, and had a few discussions with people (P. O'H being a great help) to get my head around what MVVM actually meant
I then went through the "looking at every framework" stage - and realised (again) that I hate frameworks because people try to make them do lots of stuff that then constrain me - so I went onto the "how should it really be" stage.
That's when I sat back and started work on my articles - not for CP but for me - putting stuff down in writing, having a toy application to start developing really helped me get my head around many aspects of MVVM, helped me develop my own version of a framework, that I could use simply elsewhere.
And, despite giving up and starting again many times whiole writing the articles, moving onto other projects (some using MVVM some not) I kept coming back to MVVM.
when working on non MVVM projects, I kept wishing it was MVVM as it would make things easier
So, it took me a lot of time and effort, and I've been programming for 35 years, so it was very much 'old dog, new tricks', but when I came out the end of the tunnel, I felt there was no going back.
To those at the other end of the tunnel, well, you're doing fine where you are, have fun and be happy. The tunnel is ling, often dark, and has some dead ends along the way, but if you do get through it, you'll see that there are no hairy shirts or self-whacking folks
|
|
|
|
|
I went through almost the exact same cycle except there was never a small app to say this was too complex for. I needed to drag an entire team into a proper WCF based design platform from many years of winforms development. I was refactoring some code last week and had to do the face palm, what was I thinking, no doubt I will do the same in a few more months as my understanding deepens.
My biggest bitch at the moment is that Oracle is case sensitive and insists all objects be named in uppercase, this totally f***s up my ORM code generator. I have almost identical systems in both Oracle and SQL Server and I have to write 2 distinct apps (that almost is a killer), either that or hand code all the table/field names in the ORM.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
ORM? pah - that's for sissys! Type until your fingers bleed!
I'd have thought your solution would be to uppercase everywhere?
You CAN make SQL server case sensitive too, if you want.
|
|
|
|
|
_Maxxx_ wrote: many people misunderstand MVVM (the 'there must be not code behind' ers being a
majority group!)
There really doesn't need to be in most cases. Most of the time I have seen code behind, its been that the developer was lazy and didn't have a strong enough framework. I just wrapped up an MVVM project and didn't have *ANY* code behind. I mean ZERO. All windows, dialogs, controls, etc. had the code behind .cs DELETED. Not even a call to InitializeComponent()  . I have a generic event -> command mapper in my framework, so I just use that in the XAML and I pretty much end up with as much code as I would if I would have done the code behind -- except I don't have code behind. I know its not a requirement of MVVM, but I just don't like it. It makes me feel like I'm splitting a class between 2 .cs files and I'm going to use up a lot of my time deciding if a method should go in the VM or in the code behind.
Now, I realize that if you need code to manipulate the visuals, it shouldn't go in the VM... but thats just another case of the developer being lazy. If you *really* need code to manipulate visuals, you should make it a generic / reusable control, not part of the view.
|
|
|
|
|
I found this [^]to be a good read.
Too much of heaven can bring you underground
Heaven can always turn around
Too much of heaven, our life is all hell bound
Heaven, the kill that makes no sound
|
|
|
|
|
Not really something you can teach IMO... you either have an eye for detail or you don't. If you don't have an eye for detail or don't care about stuff like aligned UI, shifted pixels, etc... you probably shouldn't be doing UI work and leave it for the guys that like that stuff.
|
|
|
|
|
Some information from Microsoft here[^].
|
|
|
|
|
Well, thats kind of what I meant. I'm a UI / designer / software engineer guy and I know what looks good & professional and what looks bad & cheezy, but its not something I can explain or teach to somebody. Its just something that I have a "feel" for. It does go beyond pixel alignment, etc. obviously... like you may have a dialog and it could be all perfectly aligned and fully 100% usable, but its possible that it could look visually more appealing if you laid it out another way. I could tell you to use the Segoe UI font on your UI and to generally use the system colors, but thats not really explaining anything.
What I'd suggest is looking at all the popular applications out there and kind of trying to figure out what people like UI wise. For example, one of the most copied UIs out there has always been Office. People have been copying it since day one. Personally, I think Office 2007 looks better then 2010, but thats just me... On the other hand, I don't think Visual Studio is that great of a UI.
|
|
|
|
|
I quite agree with you, UI design is not something you can simply explain. Your must have a sense for design in order to create a good look and feel. Beauty, they say is in the eyes of the beholder but as far as UI is concern, it's in the sense of the designer.
|
|
|
|
|
I believe it is something that can be explained to developers and can be improved if you seek to educate yourself. Don't think you will never be able to improve. Good design follows patterns just like good coding does and can be learned. If you are a Windows developer, I recommend you read Microsoft's UX guide. One of the things I like about it is they use old versions of Office and Windows to point out their own bad examples. About Face: The Essentials of Interaction Design by Alan Cooper should be on every developer's bookshelf as well. I am reading Designing Web Interfaces by Bill Scott & Theresa Neil and can recommend that as well.
|
|
|
|
|
I sure there are lot more of those good books out there that provides GUIDELINES on how to design interfaces but you should still be able to judge between good designs and bad ones relative to the project at hand, that was what I meant by having a sense for design
-- Modified Saturday, August 20, 2011 12:29 PM
|
|
|
|
|
Of course it can be taught!
Where did you get that dreamy eyed nosense?
Maybe the belief that it can't be IS the problem.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
