If you're a regular reader of my blog, you'll probably remember my pithy blog post where I stated that "It all depends..." to the question "Which Data Access Should I Use for Silverlight 3?" The reality is that much like the similar question I am confronted with at user groups for the past decade ("What data access should I use in my .NET app?"). The reasons for picking a strategy are wide and varied so I will not try to analyze all possible outcomes, but I think the different strategies need to be explained better.
The three major candidates in Silverlight 3 are Web Services (WCF/ASMX), ADO.NET Data Services and RIA Services. In any situation, any of these will work. But they are suited to different styles and requirements. Here's the abridged differences between the stacks:
The goal of Project Niagara is to democratize the validation support. The project wants to help developers add validation support to ADO.NET Data Services as well as Web Services in Silverlight. In addition, it has the goal of allowing multiple ways to supply the validation metadata to the different data access strategies. As it is my opinion that there are scenarios where attributes are not the best idea.
As RIA Services is plodding towards a release, many people are looking at it to help them with validation of data in Silverlight. Using this validation in Silverlight 3 is pretty straightforward but there are some caveats. I want to show you under the covers so you understand what is happening. In this first part of the series, let's look at what it means to use validation from the outside.
Back when Dynamic Data was being developed, a set of attributes was created to help tell the Dynamic Data folks about validation and other metadata so they could create smart scaffolds. These include:
We have made some adjustments in the Fall/Winter schedule for the Silverlight Tour. As Fall is often our busiest time of year, we decided to move some dates around to not conflict with the PDC and other conferences. Here is the new Schedule for the Silverlight Tour and the Advanced Silverlight Workshop:
Today I was working with a client and ran into a problem I didn't expect. This particular problem had to do with Silverlight consuming a WCF Service. Sometimes WCF causes me to spew four letter words. There is a class of WCF problems that cause this: connection rejection. WCF has been designed to prevent common DDoS and other attacks that could cause servers to fail or at least not serve honest requests. To this end the default size of a request is quite small. In fact, its usually 64K in size. This size is fine for most every request but occassionally when a client wants to send a collection of things to the server this size is too small. But we'll get to that in a minute. First, some background...
This particular client has a large service that's been working for quite a while, then suddenly a single call he has was being rejected. The new service call he was making was sending back a list of a couple of hundred of POCO classes. He had been downloading large lists before so on the surface this should have worked. But it didn't.
If you've been following my blog, you should know that I am keeping a pretty close watch on ADO.NET Data Services. The team recently released a second CTP of the new version with some interesting features. This CTP has some pretty compelling additions, but I am going ot focus on one in particular.
I've been teaching and using ADO.NET Data Services for a long time and I like showing off exposing a LINQ-based provider (Entity Framework, NHibernate or others) to a Silverlight application. While ADO.NET Data Services does expose its API through a REST API, the magic for me is in its use in Silverlight. In case you haven't been following along, using the Silverlight client you can issue a LINQ query through the Silverlight client (though in fairness, the full power of LINQ is not supported in the client):
If you've never had the chance to visit my sister site (http://www.silverlightdata.com), now's a good time. I've updated my examples there to include my MVVM, Prism and Declarative UI examples (to go with the skinning/switchable Astoria example). Take a look if you're doing Silverlight data-based applications.
If you're building Internet applications, you've probably been bombarded with lots of new technologies the last few years: Silverlight, Flex, ASP.NET MVC, jQuery, etc. While all of these technologies have their use-cases, many of them are pointing to something that is new and important.
I am excited to announce that my new DNR-TV episode is up at .NET Rocks. Carl and I visited while we were both at DevTeach to show off Blend's new SketchFlow functionality. If you have time, give it a spin!
It all depends...
I had a great time at DevLink this year. Met up with lots of great heartland folks and had some really interesting conversations (about Ruby and F# specifically). If you missed DevLink this year, you missed a great conference. John Keller and company put on a great show (for only $100 conference fee). The .NET Rocks panel at the end of the three days capped off a great few days in Nashville.
As regular readers of my blog know (RIA Services Concerns Squashed), I have been a lukewarm supporter of RIA Services for Silverlight. As many of you know, Brad Abrams and company have come through with their latest release (RIA Services Preview July '09) with lots of changes I've been hoping for. Honestly I haven't had time to look at the new build (probably this weekend), but I am hopeful of its overall direction. I am still somewhat tentitive about some of the basic behavior of the framework but I will hold my tongue until I have more time to dive deeper into the code.
What really concerns me is that I've talked to students and others and many are opting to building systems with RIA Services right now. This only concerns me because RIA Services is not part of Silverlight 3 and is not released. Actually, the July version is a "Preview" (something like a CTP) which means they haven't even reached Beta with RIA Services. Now many these developers are working on very long time lines and can wait until RIA Services releases, but while investigating it makes a lot of sense (and I encourage everyone do that), building production code against a framework that is still in transition is a risky venture in my opinion.
|Implementing and Securing an API with ASP.NET Core (new)|
|Building a Web App with ASP.NET Core, MVC6, EF Core and AngularJS|
|Building a Web App with ASP.NET5, MVC6, EF7, and AngularJS (Retired)|
|Best Practices in ASP.NET: Entities, Validation, and View Models|
|Front-End Web Development Quick Start|
|Lessons from Real World .NET Code Reviews|
|Node.js for .NET Developers|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||18.104.22.168||Runtime Framework||.NETCoreApp,Version=v1.1|
|App Path||D:\home\site\wwwroot||Runtime Version||.NET Core 4.6.24628.01|
|Operating System||Microsoft Windows 6.2.9200||Runtime Arch||X86|