Pixata Custom Controls
For Lightswitch

Recent Posts

Popular tags (# posts in brackets)

Anonymous types (3) ASP.NET (5) C# tricks and tips (2) Computers (4) Design patterns (3) DomainDataSource (3) Dynamic data (4) Entity model framework (7) LightSwitch (11) Linq (6) Microsoft (1) MVP (2) MVVM (2) RIA services (5) Silverlight (1) SQL Server (1) Unit testing (4) Visual Studio (5) WCF (3) WPF (2)

Archives

Categories

Blogroll - Fav Blogs

Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Actually, as I'm self-employed, I guess that means that any views I expressed here aren't my own. That's confusing!

About me

Acknowledgments

Theme modified from one by Tom Watts
C#/HTML code styling by Manoli

My rambling thoughts on exploring the .NET framework and related technologies
Home of the surprisingly popular Pixata Custom Controls For Lightswitch (well, it was a surprise to me!)

# Unit testing a Lightswitch application (Thursday, July 28, 2011)
 

If you’ve read my recent diatribes, you will be relived to know that this will be a very short post! It wasn’t going to be, but thankfully all the problems I was going to describe have been solved very simply.

Whilst tinkering around with my first Lightswitch application, I wanted to move some code into a separate class library, so it could be reused around the application. Naively, I added a C'# class library to the solution, moved the code over and then couldn’t add a reference to it from my Lightswitch project.

Whilst wondering what was going on, it dawned on me that Lightswitch is really just Silverlight underneath, so needs a Silverlight class library, not a normal .NET class library. I deleted the one I had just created, and added a new Silverlight C# class library. This time, I was able to add a reference and use the code from my Lightswitch application. Phew, one problem solved.

I then decided to write some unit tests for the class. That’s where I ran into the next problem. Normally, I just right-click a method, and choose “Create unit tests” from the context menu. Trouble was, there wasn’t a “Create unit tests” option there.

I spent rather longer than I should trying to work out how to do this, and failed. I even tried adding my own project and making into a test project, but that failed as I couldn’t add references to the appropriate test libraries. This is one of those occasions when you really wonder why Microsoft split Silverlight off from the rest of the .NET framework.

Anyway, the good news is that I just discovered that if you install the Silverlight Toolkit April 2010, you get new Visual Studio templates for unit testing Silverlight applications. They don’t work in quite the same way as normal unit tests, in that the tests themselves run in a Silverlight web application, but the basic principles are the same. You can even use the same code, and the same test attributes as you do in your normal tests.

Apparently, you can even test the UI with this framework, but I haven’t tried that. Needless to say, the fact that I could test my class library was enough to make me happy, and keep this blog post a lot shorter than it would have been - although it’s still a lot longer than it should have been, given the actual amount of useful information it contained! I must learn to be more concise.

 

Laugh and cry with me as I describe my attempts to deploy my first Lightswitch application.

Read how it all went wrong, the started to go right, then went wrong again, then went wrong some more, then... well just read the full blog post and you'll get the picture!

Categories: LightSwitch
# Lightswitch launches today! (Tuesday, July 26, 2011)
 

Having mentioned a few weeks ago that I was quite impressed with my first impressions of Microsoft Visual Studio Lightswitch, I have since had a chance to play with it some more, and I am still very impressed – perhaps even more than I was. My initial fears about it being another ASP.NET Dynamic Data fiasco seem to have been unfounded.

As promised, it provides a very fast way to produce high-quality data-driven Silverlight applications (web or out-of-browser), but seems flexible enough not to restrain you by the way the Lightswitch developers want to work. Admittedly, I am still a rank newbie with it, but have already produced most of the administrative back-end for a web site I’m developing, and have done so in a mere few hours, as opposed to the few weeks it would have taken otherwise.

What’s even better (or maybe that’s only by comparison), it doesn’t have some of the stupid design “features” that plagued Dynamic Data. For example, one of my peeves with DD was this it did not attempt to stop you trying to delete a customer who had orders in the database. However, when you tried it, the delete failed due to the obvious referential constraints, ie you can’t delete the customer if there are still orders that reference that customer. Despite having jumped through quite a lot of hoops, I never found a satisfactory way to disable the delete link. I found one way, but it was so convoluted as to be pretty useless. As if that wasn’t bad enough, DD didn’t give any graceful way to handle the inevitable exception, so the end-user was presented with a rather ugly (and very unprofessional) unhandled exception. You couldn't even tell it to do a cascading delete for those occasions when you really did want to delete the customer and everything associated with it. It was a great idea, but really badly implemented.

Not so Lightswitch! By default, the delete button is always enabled, which would give an exception if you tried to delete something that you shouldn’t, but (and this is a huge “but”), if you tried it, you got a very neat validation error shown on the screen, telling you that the record couldn’t be deleted. Next bit of friendliness is that it’s really easy to disable the delete button when you want to. You simply override the code, and handle the CanExecute method, which simply returns a Boolean, indicating whether or not the current record can be deleted. As you have full access to the current entities on the screen, this is no more complex than something like this…

partial void CustomerListDeleteSelected_CanExecute(ref bool result) {
  Customer c = Customers.SelectedItem;
  result = (c.Orders == null || c.Orders.Count() == 0);
}

Pretty simple stuff eh? You are dealing with strongly-typed entities, and simply check the properties that interest you, setting the return value as appropriate. Because Lightswitch applications are built on MVVM (basically a WPF or Silverlight-specific implementation of MVP/MVC), the framework handles the enabling and disabling of the button for you. All you need to do is set the Boolean return value of CanExecute. This makes it very easy to prevent the user from trying to delete something that they shouldn't be able to.

The other nice touch in this area is that you can specify that cascading deletes are allowed for an entity, so if you do allow them to delete a customer, all the customer’s orders can be deleted at the same time. Whilst this isn’t the sort of thing you’d want to do too often, it’s nice to know that the functionality is there if you want it.

Just last night I was reading about using custom controls in Lightswitch. This allows you to extend the functionality in pretty much any way you want, simply by using normal Silverlight controls. I haven’t tried this yet, but it looks fairly simple, and means you aren’t restricted to the controls included in the Lightswitch framework. I even saw an example of a game someone had written in Lightswitch, which whilst not being the most logical use of the framework, served well to show how easy it is to extend.

Anyway, I intend to post more technical details when I’ve played some more. In the meantime, Lightswitch launches today, although as I’m writing, it’s not yet launched. This is probably because it’s only just today in Redmond, and the Microsoft people are probably all still in bed!

# Easing web development with WebFormsMvp (Monday, July 11, 2011)
 

Always on the lookout for ways to improve my coding efficiency, I was very interested to hear about WebFormsMvp, which is a framework for writing ASP.NET web sites, based on the MVP design pattern. This post describes my initial frustrations, and eventual delight in using the framework.

In a future post, I intend to describe how to get going with WebFormsMvp, as well as how I extended it to reduce the boilerplate code even more.

Categories: ASP.NET | Design patterns | MVP | Unit testing

Putting reality aside for a moment, and imagining that this blog has at least one avid reader, then he/she may remember that some time ago, I got all excited about ASP.NET Dynamic Data, which looked like a brilliant way to produce CRUD web sites (ideal for the admin back-end of most modern web sites) in almost no time at all. The same avid reader would no doubt also remember that I learnt quite quickly that it was a huge waste of time, great for management demos, but useless for the Real World, and gave up with it.

Well, another day, another new technology from Microsoft, and here we are with very similar promises about being able to produce CRUD web sites in minutes – introducing Microsoft Visual Studio LightSwitch. A moment’s pause over the name will probably reveal the pun on another Microsoft technology, SilverLight. LightSwitch is being promoted as the equivalent for SilverLight that Dynamic Data was for ASP.NET, in other words, a RAD development tool that allows you to produce CRUD sites very quickly.

So, why am I bothering? After all, my previous experience was, shall we say, less than positive! Read more to find out...