I am new to Entity Framework but have spend a lot of time reading through the snippets of the code, Julie Lerman book, Scott Gu's blog...
I think I have come to understand a lot, but now am at a point when all needs to be tied together in quite complex layered project.
Since I have no background in developing for the web, and all examples that I could find are either simple console applications or are using ASP & MVC I have the hard time understanding the (ASP) examples posted - what is applicable in developing desktop application using WPF and MVVM?
In short, is there any layered example that is not simple console application or ASP.NET, that has CRUD elements?
This might help:
Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App
Related
I have recently read about the 3 tier architecture, and i would like to know how to apply it in developing Desktop Applications using WPF and C#.
any reference to external articles or resources is appreciated.
"3-tier architecture in WPF" instantly makes me answer you "MVVM - Model View View-Model"
This quick start tutorial can help you getting started with it.
I highly recommend working in MVVM with WPF anyway. I'd even say that, using WPF without working in MVVM does not make a lot of sense imho
You also have a more strict framework named PRISM, google it if you want
Anyway, for MVVM, a lot more anwers are listed in:
this thread
We have lots of project developed using .net 2.0 version if I want to convert those project to WPF then what will be the approach. Please discuss in detail.
to let the migration to WPF easy, be sure that your existing code doesnt contains a high coupling between GUI and your Business layer, if it's the case the most important step is to refactor your existing code, so your GUI code will contains only what's related to GUI.
And after this step the part of your project to migrate will be not the big one, it will concerns only the GUI logic.
When I did this kind of migration from winform to WPF , we spent more time to remove coupling between GUI and other layers than to migrate the GUI layer, due to high coupling betwn GUI and other layers.
Having gone through a similar exercise I'll tell you that it can be done but there are some challenges.
Step1: Just for clarification when we say WPF some people mean Silvelright / web. WPF is not Silverlight so you need to clarify I want to migrate existing applicaitons to WPF thick client applications. Since you stated WPF I am assuming you mean thich client/windows based applications so we'll go that route. (I'll mention SL at the end)
Step 2: Evaluate your projects from the code level for the most part refactoring the code is fairly easy. Since you are migrating from .net 2.0 to .net 4.0 I would really look at how many of your classes are defined, and see what can be refactored or in some isntances completely redesigned. THis leads us directly into step 3.
Step 3: Pick a design pattern. One of the tricky parts is coming to terms with a new design patterns such as MVVM for WPF. More than lilkely you will want to strip out and redesign the entire UI. As a result you will also want to utilize a proper design pattern (MVVM) or some flavor of that. This will also tie back to step two as some of your code will need to change to support your design pattern.
There are a ton of resources online for MVVM as well as UI development. If you are looking for reading materials I would look to WPF 4 unleashed as well as WPF illustrated. Both are good reads to help you get up to speed on the UI components how they work and the proper approach to using them in a project.
Get familar with .net 4 and the use of collections, types and of course the numerous new classes for wpf.
Disclaimer: You can in many instances create a WPF application usign tradition winform layout and practices. Whether this is right or wrong is a matter of opion of the developer. My personal opinion is that yes you can forego learning new design patterns and use a winform approach but you will not gain the full benefit and capabilities of the framework using this approach.
And finally if you are planning to migrate these apps to the web (silverlight) your work will be a little more of a challenge. Silvelright does have a little higer learning curve and there are a few more rules (security, asynchronous calls, web services etc) that must be learned, and followed. I have foudn that in creating a migration that it is easier to migrate from Siverlight to WPF that vice versa. As Microsoft continues to improve Sivelright I think we will get to the point to where the code is interchangeable between the two patterns however right now it's not there.
Conduct a search online but here are a few links to help you get started:
Scott Guthrie (Silverlight) http://weblogs.asp.net/scottgu/default.aspx
Josh Smith (WPF MVVM) http://joshsmithonwpf.wordpress.com/
best of luck
We are trying to pick a modular programming solution at my work. The choice right now is Prism or ASP.NET Web Parts.
One Boss person asked if you could wrap a Prism Module in an ASP.NET Web Part so they can be used anywhere (kind of a "can I have my cake and eat it too" kind of question.)
While I don't think this is a feasible solution, I don't really know.
Anyone out there that knows some about both Web Parts and Prism that could hazard an explanation as to if this could or could not work?
The latest Prism version only supports WPF & Silverlight. It does not provide any default support for the ASP.Net programming model.
If you (or your boss) are looking for guidance for decoupled applications with ASP.Net, you can probably check ASP.Net MVC which shares many of the Prism core concepts (presentation patterns, containers, areas/regions). Specifically, p&p developed a guidance about developing Web Apps which you can find here and download from here.
I hope this helps.
I am new for both concepts.
1) I want to know that MVC and WPF is same concepts but WPF for desktop while other is for WEB ?
2) Will be easy to learn other one If i learn one of them ?
I think you probably meant "ASP.NET MVC" technology when you were talking about "MVC" (based on the tags of your question). Anyway, here are a few points that may clarify what is going on:
ASP.NET MVC is a technology for developing web applications based on the model-view-controller (MVC) pattern. You can twist it a little bit, but the framework is specifically desgined to work with this pattern.
WPF is a technology for developing windows applications. You can use various different design patterns when writing WPF applications, but the most popular one these days is called model-view-viewmodel (MVVM). You could also use the MVC pattern (organization of components) when writing WPF applications, but that wouldn't work as nicely as more native approaches.
So, regarding your questions:
They are not the same concepts - the technologies are different and the usual patterns (ways of organizing code) used with the two technologies also differ.
Learning one technology may make it easier to understand the other one slightly, because they are both .NET GUI frameworks and share some concepts. However, I don't think this will help a lot.
MVC (model-view-controller) is a design pattern, and is not specific to a particular technology set.
WPF (Windows Presentation Framework) is Microsoft's windowing library, and can be used in an MVC-designed system. However there's nothing to enforce this and MVC pattern usage can certainly be abused with WPF.
MVC is a widely used pattern and familiarity with it is going to be useful regardless of the technology set used (whether it's web-based, WPF, Swing etc.). Note that MVC is usually associated with GUIs, but there's no particular restriction and the pattern can be used wherever a model and its changes need to be reflected to different consumers with different views on that data.
No,
WPF and Silverlight are much more closely related than WPF and ASP.NET MVC. Silverlight is a seperate runtime and is basically a subset of .NET; Silverlight uses XAML markup for the UI, which supports a subset (and some web-specific) features from WPF and .NET.
ASP.NET MVC is Microsoft's implementation of the MVC pattern. What differentiates MVC from WebForms ("classic" ASP.NET web-development) is that MVC assists in using best-practices and giving the developer a high-level of control of the output of the application--WebForms was more RAD (Rapid Application Development) driven, making it easy to begin to work with--but putting some concerns about best-practes, pattens, and control to the wayside.
As for which is easier: MVC will likely be quicker to start with, but doing full-blown web-development requires a set of technologies (HTML/CSS/JavaScript/.NET) whereas WPF keeps your required knowledge more focused (XAML/WPF/.NET).
No. MVC is a pattern while WPF is a Microsoft technology.
You could with some effort likely use the MVC pattern in WPF but more popular in WPF is MVVM nowadays. MVC itself is not restricted to web only.
Grz, Kris.
2) Will be easy to learn other one If
i learn one of them ?
Shure: They both can be programmed using c# or vb. And they both can be programmed using Visual Studio.
But the same is true for any technology that incorporates .NET technology (Winform, ASP.NET, Silverlight...)
I absolutely have no idea about Silverlight except that it is a Microsoft technology.
Having nearly completed a Computer Science degree, having programmed in C# for a few years in a work environment - have a good knowledge of Java and OO techniques - how hard is the road of average Silverlight programming? I've been offered some work DAMN IT!
I've mucked around with PHP, HTML and nearly no CSS..
Would I need a strong web programming background in order to pick it up?
I like Ben's answer, and he's right that a huge bonus of learning Silverlight is that you don't have to worry about the stateless model. However, there are a few parts of Silverlight that are less easy to learn:
Styling & control templates - These concepts look like CSS at first but there's a good bit more that you can do with them such as completely overriding the visual aspects of the control. Also, modifying the styles of existing controls is one thing and learning how to create your own control that can be easily styled is quite another.
Database connectivity - If you're anything like me the first thing you'll want to do after you write a "hello world" test is hook up to a Db and pull down some data. Since Silverlight can't directly connect to a Db you'll have to learn one of 3 techniques to move data between the browser and server: 1. WCF + your custom service methods + LINQ to SQL or LINQ to EF or whatever data access you choose. 2. ADO.NET Data Services (great way to start out) 3. .NET RIA Services (once you've realized that you need your data access technology to play nice with data binding and honor biz rules).
Security - You need to learn another part of the MS technology stack to get this working properly, ASP.NET Application Services. It should take more than a few hours to hook things up but it is another technology to learn.
Browser navigation, search engine friendliness & deep linking - Things you take for granted writing a traditional web app will take a bit more work in SL. You can use .NET RIA Services to handle browser navigation & deep linking, others have written about making your site friendly to search engines (and I don't know how ;).
What I'm trying to highlight here is that while learning the basics of Silverlight is easy, you'll probably run into other parts of the MS technology stack that you'll need to learn to get your work done. The beautiful thing here is that all of the technologies come from 1 vendor with a single focus and they work really well together. I shudder when I think about all the different technologies you'd need to pull off my current SL app in the open source domain.
Pick up the book "Silverlight Unleashed" and go to http://silverlight.net/GetStarted to start learning. Scott Gu's 8 part blog posting (#3 on that Getting Started web page) was one of the first things I read about Silverlight and is hugely helpful.
Unless your Silverlight app has to interact with a traditional web page, you don't need to know anything about traditional web UI technologies.
If you've done any desktop UI development you'll find Silverlight much easier to pick up than any web UI paradigm. Compared to the unholy mess that is css + html + javascript combined with ever-changing browsers and fourteen other hundred-author web "standards", Silverlight is a walk in the park.