Seeking advice for learning how to create small LOB applications in C#
-
Background: Lots of Excel modelling (20+ years), lots of Excel VBA, plenty of ad hoc T-SQL, and some rudimentary WinForms apps with VB.Net. Have begun the transition from VB to C#, and have learned enough XAML to be dangerous. In our department we occasionally need to collect user input for some relatively simple SQL Server databases - with typical CRUD activities. These will USUALLY be short term initiatives, so the effort that goes into creating the apps can't be too great. I'll be a part time 'programmer' creating these apps. I'm looking at WPF as the vehicle for these apps, and it sure seems that MVVM can simplify the UI a great deal. I think I can handle the Views and ViewModels. Where I am struggling, though, is finding relevant examples on the Model aspect. It seems examples are either too simple, with a local XML file providing the data for a class or two, or they are (to me) too complex, with ISomeObjectRepository and SomeObjectRepository, IUnitOfWork and UnitOfWork, etc. Much as I would like to understand all this "stuff," programming these apps is not my day job, so I need some straightforward examples/tutorials for building reasonably reliable apps. I'm also looking for advice on whether working through learning MVVM for its occasional use is warranted. Am I better off abandoning MVVM and simply binding the UI to the classes that EF or LinqToSQL create? Or, is somebody in my position really best advised to wait until LightSwitch is out of beta? Thanks in advance!
-
Background: Lots of Excel modelling (20+ years), lots of Excel VBA, plenty of ad hoc T-SQL, and some rudimentary WinForms apps with VB.Net. Have begun the transition from VB to C#, and have learned enough XAML to be dangerous. In our department we occasionally need to collect user input for some relatively simple SQL Server databases - with typical CRUD activities. These will USUALLY be short term initiatives, so the effort that goes into creating the apps can't be too great. I'll be a part time 'programmer' creating these apps. I'm looking at WPF as the vehicle for these apps, and it sure seems that MVVM can simplify the UI a great deal. I think I can handle the Views and ViewModels. Where I am struggling, though, is finding relevant examples on the Model aspect. It seems examples are either too simple, with a local XML file providing the data for a class or two, or they are (to me) too complex, with ISomeObjectRepository and SomeObjectRepository, IUnitOfWork and UnitOfWork, etc. Much as I would like to understand all this "stuff," programming these apps is not my day job, so I need some straightforward examples/tutorials for building reasonably reliable apps. I'm also looking for advice on whether working through learning MVVM for its occasional use is warranted. Am I better off abandoning MVVM and simply binding the UI to the classes that EF or LinqToSQL create? Or, is somebody in my position really best advised to wait until LightSwitch is out of beta? Thanks in advance!
Duke Carey wrote:
These will USUALLY be short term initiatives
Given this I would hesitate on using WPF. It seems it would create an issue of users having many apps on their systems that will be outdated and attempting to enter data that may no longer be valid or useful. I would consider a web interface where the apps could be easily taken out of service after the initiative passed, or possible ClickOnce deployment with the app run from a server. If the data structure is relatively simple as you say I would say MVVM isn't worth the effort at this point. However, you would certainly want to expend some thought on creating a reusable architecture. Is InfoPath and option for you?
I know the language. I've read a book. - _Madmatt
-
Duke Carey wrote:
These will USUALLY be short term initiatives
Given this I would hesitate on using WPF. It seems it would create an issue of users having many apps on their systems that will be outdated and attempting to enter data that may no longer be valid or useful. I would consider a web interface where the apps could be easily taken out of service after the initiative passed, or possible ClickOnce deployment with the app run from a server. If the data structure is relatively simple as you say I would say MVVM isn't worth the effort at this point. However, you would certainly want to expend some thought on creating a reusable architecture. Is InfoPath and option for you?
I know the language. I've read a book. - _Madmatt
Thanks for taking the time to answer Mark. Your comment about MVVM resonates, but I've already dummied up/prototyped one WPF app that, immediately after a demo, required significant changes and all most of the code behind had to be scrapped (probably tells you something about my coding skills). Thus, the command structure and ViewModels tug at me as being a real benefit. I guess what was left unstated in the original question was that using WPF first might allow us to easily migrate to Silverlight, if we can get the corporate folks to grant us access to a server. That's all locked down pretty tight right now, and I feel I'm viewed as an anarchist for asking for server access. So, the deployment of any app - WinForm, WPF, or web-based - is fraught with problems of one sort or another. InfoPath was tried once (not my effort) but, on the one hand, the data demands outstripped the SharePoint version's abilities and, on the other, few people have it on their desktops. The SharePoint hosted form had an issue with the data not fitting into a simple list format, and in our apps we'll be dealing with 5 or 6 related tables. I've looked at some of the videos for LightSwitch and it looks as though it will allow somebody like me to quickly create smaller apps. I just worry that some business requirement will come up will be JUST beyond the reach of what LightSwitch can do, and then I'd be back to square one, so it seemed best to ask for help here.
-
Thanks for taking the time to answer Mark. Your comment about MVVM resonates, but I've already dummied up/prototyped one WPF app that, immediately after a demo, required significant changes and all most of the code behind had to be scrapped (probably tells you something about my coding skills). Thus, the command structure and ViewModels tug at me as being a real benefit. I guess what was left unstated in the original question was that using WPF first might allow us to easily migrate to Silverlight, if we can get the corporate folks to grant us access to a server. That's all locked down pretty tight right now, and I feel I'm viewed as an anarchist for asking for server access. So, the deployment of any app - WinForm, WPF, or web-based - is fraught with problems of one sort or another. InfoPath was tried once (not my effort) but, on the one hand, the data demands outstripped the SharePoint version's abilities and, on the other, few people have it on their desktops. The SharePoint hosted form had an issue with the data not fitting into a simple list format, and in our apps we'll be dealing with 5 or 6 related tables. I've looked at some of the videos for LightSwitch and it looks as though it will allow somebody like me to quickly create smaller apps. I just worry that some business requirement will come up will be JUST beyond the reach of what LightSwitch can do, and then I'd be back to square one, so it seemed best to ask for help here.
Duke Carey wrote:
is fraught with problems of one sort or another.
It goes without saying that these types of issues need to be corrected, or mitigated, before any project has a chance at success.
Duke Carey wrote:
some business requirement will come up will be JUST beyond the reach of what LightSwitch can do
Yes. And that limit will come very quickly. Good luck
I know the language. I've read a book. - _Madmatt
-
Background: Lots of Excel modelling (20+ years), lots of Excel VBA, plenty of ad hoc T-SQL, and some rudimentary WinForms apps with VB.Net. Have begun the transition from VB to C#, and have learned enough XAML to be dangerous. In our department we occasionally need to collect user input for some relatively simple SQL Server databases - with typical CRUD activities. These will USUALLY be short term initiatives, so the effort that goes into creating the apps can't be too great. I'll be a part time 'programmer' creating these apps. I'm looking at WPF as the vehicle for these apps, and it sure seems that MVVM can simplify the UI a great deal. I think I can handle the Views and ViewModels. Where I am struggling, though, is finding relevant examples on the Model aspect. It seems examples are either too simple, with a local XML file providing the data for a class or two, or they are (to me) too complex, with ISomeObjectRepository and SomeObjectRepository, IUnitOfWork and UnitOfWork, etc. Much as I would like to understand all this "stuff," programming these apps is not my day job, so I need some straightforward examples/tutorials for building reasonably reliable apps. I'm also looking for advice on whether working through learning MVVM for its occasional use is warranted. Am I better off abandoning MVVM and simply binding the UI to the classes that EF or LinqToSQL create? Or, is somebody in my position really best advised to wait until LightSwitch is out of beta? Thanks in advance!
As another guy in this thread said, if you are just doing small "one-off" apps, MVVM definitely isn't worth the trouble. Actually, let me rephrase that: *PROPER* MVVM isn't worth the trouble for small "one-off" apps. Lots of guys say they are doing MVVM, but when you look at their code, its more like "make believe MVVM" since they've broken a lot of MVVM tennants. I'm not sure where you fall in that category (no offense intended), but if you aren't doing MVVM right, or are just doing it because "its what the cool kids are doing", you are asking for trouble and hair pulling. You should only use MVVM where its appropriate and understand why you are using it. If your MVVM infrastructure is larger then your app "u r doing it wrong!!" :). I'm even going to go a step further... for small "one-off" apps, why even bother with WPF? WPF is intended for rich customized applications. If you are just doing a cookie cutter form with stock controls, WPF ain't worth the hassle. Lots of stupid small things that would take you one line of code in Winforms would take pages and pages of code in WPF. WPF is a huge time saver in certain areas, but its also a massive time killer in other areas. As for WPF vs. Silverlight... its straight forward to go from Silverlight to WPF since Silverlight is a subset of WPF. Not so easy to go the other way.
-
Thanks for taking the time to answer Mark. Your comment about MVVM resonates, but I've already dummied up/prototyped one WPF app that, immediately after a demo, required significant changes and all most of the code behind had to be scrapped (probably tells you something about my coding skills). Thus, the command structure and ViewModels tug at me as being a real benefit. I guess what was left unstated in the original question was that using WPF first might allow us to easily migrate to Silverlight, if we can get the corporate folks to grant us access to a server. That's all locked down pretty tight right now, and I feel I'm viewed as an anarchist for asking for server access. So, the deployment of any app - WinForm, WPF, or web-based - is fraught with problems of one sort or another. InfoPath was tried once (not my effort) but, on the one hand, the data demands outstripped the SharePoint version's abilities and, on the other, few people have it on their desktops. The SharePoint hosted form had an issue with the data not fitting into a simple list format, and in our apps we'll be dealing with 5 or 6 related tables. I've looked at some of the videos for LightSwitch and it looks as though it will allow somebody like me to quickly create smaller apps. I just worry that some business requirement will come up will be JUST beyond the reach of what LightSwitch can do, and then I'd be back to square one, so it seemed best to ask for help here.
Duke Carey wrote:
So, the deployment of any app - WinForm, WPF, or web-based - is fraught with problems of one sort or another.
I'd like to be there when you tell them your Silverlight app/WCF service needs cross-domain permissions. The looks on the security guys' faces would be priceless... :)
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
Duke Carey wrote:
So, the deployment of any app - WinForm, WPF, or web-based - is fraught with problems of one sort or another.
I'd like to be there when you tell them your Silverlight app/WCF service needs cross-domain permissions. The looks on the security guys' faces would be priceless... :)
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001John Simmons / outlaw programmer wrote:
I'd like to be there when you tell them your Silverlight app/WCF service needs cross-domain permissions.
JSOP - I was kinda hoping you might carry the water for me on that one, since you could 'splain it so much better than me!
