I've actually done a LOT of reading about WPF. I feel like I understand how it works fairly well at this point, and I am impressed with its capabilities. It makes much spiffier user interfaces than Windows Forms. My concern with it is threefold.
1) Performance. i.e. Under real world circumstances, involving older computer with limited memory and slow CPUs, will it be as fast or faster than Windows Forms? 2) Reliability. Is WPF robust enough to rely upon day in and day out? Windows Forms, for all its drawbacks, is proven and mature. WPF is still being developed. Does it still have quirks and unreliable features, or is it stable and improving rapidly? Form the small amount I have seen, it appears to be solid, but I haven't used it on a daily basis yet. 3) Learning curve. I am studying WPF regularly and am starting to get the hang of it. I am much faster at picking up new tech than everyone else on my team. Is the learning curve for WPF too much to expect of them? Related to learning curve is a unforgiving fact I have to deal with. I have very few members on the team, too few honestly, with no hope of the boss hiring more. I think switching to WPF may require I have one of them devote their entire time to mastering WPF and building screens and controls for others to use. I can't be that person because I've got to specify the DB schema, design the object model, and document the workflow everyone will be using to guide development. My only logical choice would be one of the people who isn't very comfortable with OOP because he understands the user interface requirements better than anyone, including me. Choosing him means I have to spend a LOT of time holding his hand, teaching him how to use WPF to its fullest. Not ideal. I don't question what LINQ can do. I've read enough examples to grasp that pretty clearly. I like the syntax and flexibility. I am surprised, albeit minorly, that LINQ 2 SQL is not going to be supported much longer. Doesn't bother me much. I am going to restrict CRUD access to the DB via stored procedures. I am leaning heavily towards using the Entity Framework to bang against the stored procedures, so LINQ to Entity works just fine. My questions about LINQ and the Entity Framework are again, performance, reliability, and learning curve. You haven't said much regarding those factors, but based upon your obvious enthusiastic support of LINQ and EF I'm assuming you find performance and reliability are acceptable. Learning curve is a bit less of an issue here since I and my best programmer will be doing most of the work building the objects that will use these technologies the heaviest. WCF is my biggest weak point at this moment. Again I am assuming you find the performance and reliability acceptable. My understanding is it will make building distributed applications easier. I'll run with it from there. Thanks again for your feedback. - R.B. Davidson On Feb 4, 1:59 pm, Brandon Betances <[email protected]> wrote: > I also want to note that LINQ is not going to be supported for long. > (LINQ2SQL atleast) Here's why. > > I attended a LiveMeeting last night, Although I couldnt post the link fast > enough to get your attention. It was about the ADO.NET Entity Framework. The > EF is cool, because it has alot of features we called for in LINQ. It can > also be used with any type of DB (Oracle, MySQL, etc.) > > You can use LINQ to query EF. Which means instead of using a SQL command, > you can access data like this: > > EntityFramework ef = new EntityFramework(); > var stuff = from s in ef.Customers > select s; > > DataGrid.DataSource = stuff; > > Alot easier, yea? > > And about WCF, the reason it is cool is because it creates Web Services as, > esentially, a whole other application. > > WPF separates the presentation layer of your app from the logic.
