Training team on .NET and C#
-
Hi, Next month I have to lead a three day hands on.NET C# training workshop for our development group. I am new to the organization (about 3 months) and was brought in for my .NET & C# experience so I will be training the senior members of the team who are all long time Visual FoxPro developers. As a group everyone understands the need to move towards n-tier application development, but the current VFP methodology relies heavily on code behind the form. Anybody out there have any good course outlines or suggestions for course materials? We are looking at a pretty hefty paradigm shift here and I want to start off on the right foot. Thanks. Tim
-
Hi, Next month I have to lead a three day hands on.NET C# training workshop for our development group. I am new to the organization (about 3 months) and was brought in for my .NET & C# experience so I will be training the senior members of the team who are all long time Visual FoxPro developers. As a group everyone understands the need to move towards n-tier application development, but the current VFP methodology relies heavily on code behind the form. Anybody out there have any good course outlines or suggestions for course materials? We are looking at a pretty hefty paradigm shift here and I want to start off on the right foot. Thanks. Tim
I've made the shift from VFP a couple yrs ago. First to Java. Then I moved to another company within the same industry using C#. A couple observations based on my experience: 1) The fact that there is code behind the form is not the biggest, or even a big hurdle to jump over. I didn't have any problems with understanding that a method that I wanted to call is in a separate class or even a separate DLL. 2) Things that are different enough that it will take sometime to get everyone on the same page: a) Inheritance/Polymorphism - It's possible to get some of this functionality in Foxpro, so the difficulty of this one depends on the crew you work with. But things that I've seen some get hung on are Encapsulation, Interfaces. Good class design many get hung up on. But I've examples of those new to dotnet adding methods that manipulate the customer class to the order class, etc. b) Data Handling - There's a big, big difference between data handling in .net and Foxpro. There are people still clinging to VFP because they think that's the only tool that handles data correctly. Good luck on this one. c) Collections - VFP only has arrays. I find that you use collections a whole lot more then I ever used arrays in Foxpro. Something that I found very useful would be a fairly simple app, but enough complexity to give you enough to cover in 3 days. An order form with customer information. And the data stored in a database.
-
I've made the shift from VFP a couple yrs ago. First to Java. Then I moved to another company within the same industry using C#. A couple observations based on my experience: 1) The fact that there is code behind the form is not the biggest, or even a big hurdle to jump over. I didn't have any problems with understanding that a method that I wanted to call is in a separate class or even a separate DLL. 2) Things that are different enough that it will take sometime to get everyone on the same page: a) Inheritance/Polymorphism - It's possible to get some of this functionality in Foxpro, so the difficulty of this one depends on the crew you work with. But things that I've seen some get hung on are Encapsulation, Interfaces. Good class design many get hung up on. But I've examples of those new to dotnet adding methods that manipulate the customer class to the order class, etc. b) Data Handling - There's a big, big difference between data handling in .net and Foxpro. There are people still clinging to VFP because they think that's the only tool that handles data correctly. Good luck on this one. c) Collections - VFP only has arrays. I find that you use collections a whole lot more then I ever used arrays in Foxpro. Something that I found very useful would be a fairly simple app, but enough complexity to give you enough to cover in 3 days. An order form with customer information. And the data stored in a database.
Thanks for your comments. The problem that I found coming from a code behind form (and I was there myself at one time) is that you tend to address of the problem domain through the lens of the user interface. And that becomes a problem when on day one you understand you are developing Windows desktop app and then a month later you are duplicating some or all of the functionality in a web app, or a web service. I agree with you that Inheritance, polymorphism & interfaces may be difficult areas. Also C# adds some other useful, but new things to the mix like abstract classes, structures, collections, etc. Tim
-
Thanks for your comments. The problem that I found coming from a code behind form (and I was there myself at one time) is that you tend to address of the problem domain through the lens of the user interface. And that becomes a problem when on day one you understand you are developing Windows desktop app and then a month later you are duplicating some or all of the functionality in a web app, or a web service. I agree with you that Inheritance, polymorphism & interfaces may be difficult areas. Also C# adds some other useful, but new things to the mix like abstract classes, structures, collections, etc. Tim
You're correct about the code behind. But it still shouldn't be a major concern. Code's code. Where to put it shouldn't be a major concern. Especially in the beginning. It all get's back to encapsulation. And that encompasses a lot more then just code behind. So I think you have to concetrate there. Codebehind is just a symptom of not doing proper encapsulation. In this case separation of data logic from ui logic. The important question thou, is what level are the Foxpro guys? Are they older, more set in their ways? Do they try to create lots of class libs so their getting a lot of reuse of their code?
-
You're correct about the code behind. But it still shouldn't be a major concern. Code's code. Where to put it shouldn't be a major concern. Especially in the beginning. It all get's back to encapsulation. And that encompasses a lot more then just code behind. So I think you have to concetrate there. Codebehind is just a symptom of not doing proper encapsulation. In this case separation of data logic from ui logic. The important question thou, is what level are the Foxpro guys? Are they older, more set in their ways? Do they try to create lots of class libs so their getting a lot of reuse of their code?
Again I agree. You are right in that the core issue is encapulation. There does not seem to have been a lot class libs developed so reuse will be another factor. The guys (and one gal - my boss!) are long time FoxPro developers, but are reasonable and open to change. No one is dragging their feet in any way, but the challenge will be moving to .NET while continuing to support a large VFP application base in the organization. The trick will be starting a low enough level to give everyone a good foundation without insulting anyone's intelligence. To complicate things a bit more, the plan is to also incorporate a third party business object framework into the development mix. One of my tasks has been to evaluate this framework. Somethings about it I like, some I don't, but a big factor for me is the the framework developer uses untyped DataSets to back up the business object layer. No problem with this approach, but I can see that having a good grasp of ADO.NET, DataSets, etc. will be important in understanding how this framework functions and using it effectively. I am a little uncomfortable in having the folks here blindly using this framework without some understanding of the ADO.NET at it's core. I may have to tackle some .NET , C# and VS basis in the first three days and then cover ADO.NET in more detail later. Tim
-
Again I agree. You are right in that the core issue is encapulation. There does not seem to have been a lot class libs developed so reuse will be another factor. The guys (and one gal - my boss!) are long time FoxPro developers, but are reasonable and open to change. No one is dragging their feet in any way, but the challenge will be moving to .NET while continuing to support a large VFP application base in the organization. The trick will be starting a low enough level to give everyone a good foundation without insulting anyone's intelligence. To complicate things a bit more, the plan is to also incorporate a third party business object framework into the development mix. One of my tasks has been to evaluate this framework. Somethings about it I like, some I don't, but a big factor for me is the the framework developer uses untyped DataSets to back up the business object layer. No problem with this approach, but I can see that having a good grasp of ADO.NET, DataSets, etc. will be important in understanding how this framework functions and using it effectively. I am a little uncomfortable in having the folks here blindly using this framework without some understanding of the ADO.NET at it's core. I may have to tackle some .NET , C# and VS basis in the first three days and then cover ADO.NET in more detail later. Tim
If they don't use classlibs in their Foxpro app, you've got some big hurdles ahead. That they sound open to change, and actually wanting to change are 2 different things thou. It really frustrated me when I still used to attend Foxpro events, or Foxpro forums on the net when Foxpro people would complain all the time how dotnet did something in such a poor way compared to Foxpro. Or that they could do x in one line of code in Foxpro, but they can't figure out how to do it in dotnet. Another reason why I would be hesitant to buy into their being open is I've got a bud working in a VB shop. So they're trying to transition from VB6 to dotnet. And he is frustrated because they all claim they want to do it right, but concepts like encapsulation seem to evade them. There are a couple framework's written for dotnet by ex-Foxpro people. I would assume they selected one of those. I would have hoped that they would have left any of those kind of decisions up to you. They obviously would not have the knowledge to properly evaluate a tool like that. So they've locked themselves in without knowing the why's and wherefore's.
-
If they don't use classlibs in their Foxpro app, you've got some big hurdles ahead. That they sound open to change, and actually wanting to change are 2 different things thou. It really frustrated me when I still used to attend Foxpro events, or Foxpro forums on the net when Foxpro people would complain all the time how dotnet did something in such a poor way compared to Foxpro. Or that they could do x in one line of code in Foxpro, but they can't figure out how to do it in dotnet. Another reason why I would be hesitant to buy into their being open is I've got a bud working in a VB shop. So they're trying to transition from VB6 to dotnet. And he is frustrated because they all claim they want to do it right, but concepts like encapsulation seem to evade them. There are a couple framework's written for dotnet by ex-Foxpro people. I would assume they selected one of those. I would have hoped that they would have left any of those kind of decisions up to you. They obviously would not have the knowledge to properly evaluate a tool like that. So they've locked themselves in without knowing the why's and wherefore's.
I started way back in Clipper 5.x (I was lucky I did not have to work much with Summer 87) and was fortunate to be mentored by a fellow who understood the advantages of developing reusable libs even in the pre OO DOS days. When it came time to move to Windows, I went with CA's Clipper migration path which was Visual Objects. VO was ultimately a pretty good development platform (although Version 1 was pretty near useless). IMHO VO was a stronger in OOD compared to VFP and I think that gave me an advantage when moving to .NET As I said before, the framework they are looking at is not all that bad for the price, but I think you need a decent understanding of the .NET framework to get the most out of another framework layered on top. Tim