Because you are reading a development book, chances are that you may be familiar with Visual Studio. Depending on how long you’ve been writing applications, you may have grown up with Visual Basic or Visual C++, or you may have written classic ASP. In more recent times, you have likely done some WinForms, WebForms, Silverlight, and WPF.
If you’ve done SharePoint development, then you’ve certainly had experience writing server-side ASP.NET. Several years ago, a SharePoint trainer compared the reaction many developers have when starting SharePoint development to the grieving process after the loss of a loved one.
It’s an apt comparison, as traditional SharePoint development can be pretty challenging. Typically, one embarks on the adventure by installing a local hypervisor such as VMware or Hyper-V, and then installing Windows Server and Active Directory. The next step is to install SQL Server, SharePoint Foundation, SharePoint Server, Visual Studio, and all the related hotfixes. Then after all of that, you get to configure SharePoint on that virtual machine, learn about the application programming interfaces (APIs), and then begin to develop. In addition, we often learn the hard way that SharePoint objects don’t always dispose of themselves correctly, leading to memory leaks if the right patterns aren’t followed.
Once you’ve built a pretty complex stack of software and completed some serious learning, you quickly realize that the hardware required for SharePoint development is much more then you have in place. You might have some performance troubleshooting skills in Windows, so you decide to run performance monitor. You notice a spike in your average disk queue length as you do a build and deploy, because the build and deploy process for traditional SharePoint development is very disk intensive. Each time you build your code, you make a special cabinet file called a .WSP. Visual Studio then retracts the existing version of the solution, deploys your new solution package and then restarts the process hosting SharePoint. After you’ve gone through this process a few times, you may do what most SharePoint developers do: walk down the hall to your manager and say “This isn’t gonna work.” You’ll cite the need for more RAM, a solid state disk, and maybe an external hard disk with an eSATA or USB3 connection.
In moving to traditional SharePoint development, you can really lose something—productivity. When developing for ASP.NET, you can make a change, hit F5, and see the result immediately. To build real line of business (LOB) applications, we need to get back to that level of productivity. The patterns we are going to explore will recapture that productivity, and then some. LightSwitch will give you the tools to build a LOB application and integrate it with SharePoint. Best of all, it will be fast and easy!
Let’s start out with some vocabulary. CRUD stands for create, read, update, and delete. If you’ve written a business application, regardless of language or technology, you’ve written a lot of CRUD. Let’s talk about what’s typically involved:
Design a database table.
Write a create or insert stored procedure.
Write a read or browse stored procedure to get data.
Write an update stored procedure.
Write a delete stored procedure.
Create a data access layer in your code with methods for each of the CRUD operations.
Depending on your design, you may create a data transfer object (DTO) to pass data between tiers of your application.
Create a thin business layer with methods for each of your CRUD operations.
Layout and data bind controls for a browse page with a delete button on each row.
Layout and data bind controls for a details page to edit.
Layout and data bind controls for a create new item page.
At this point, you may be thinking to yourself: “That’s a lot of CRUD! This feels like I’ve done a ton of work, and other than building my data model, nothing I’ve done has added any business value.” You’re totally right. And you aren’t even done yet because you haven’t written any logic to implement business rules. So back to coding you go...
Add some client-side JavaScript formatting of special fields like date pickers, phone numbers, and date/time viewers. If you’re new to programming, there are some more skills to learn here.
Add client-side validation for required fields, min and max ranges on number fields, and spend some time hacking around with a regular expression to validate your email address.
Add a summary at the top of the page that lists all the validation errors for your users.
That was a lot of work writing JavaScript, but it was worth it. You now have a slick app that you’ve testing in your browser, and your users will love it. Before you ship it, you put your code through a security review and they turn off JavaScript in the browser, and your amazing application with great client-side validation is defenseless. So back to coding you go.
Add new validation logic on each of your business layer methods to perform the same validations you are doing in JavaScript on the client. You have some creativity here because you’re writing it from scratch. You might return an object with errors or maybe just throw an exception that is handled higher up in the stack.
Either way you’ll need to handle it on the user interface side. Write some more code to display the error messages from your business layer. Keep in mind when writing these that the only time they will ever display is if client-side validation fails and the secondary validation on the business layer is needed.
At this point, you’ve spent about a week coding your application. That said, it’s a pretty simple single table application. Imagine the work you’d do if you had added drop-down lists from other tables, JavaScript and web services to make those drop-downs support type ahead, and additional CRUD pages to maintain the items in those drop-downs. While Visual Studio is better than writing an application in Notepad or Emacs, the traditional application development pattern is just too much work for too little value.
Since the mid-1990s, Microsoft has spent a lot of effort on new data access patterns and related plumbing. There was DAO, RDO, ADO, ADO.NET, Recordsets, DataSets, DataReaders, TableAdapters, CommandObjects, ParameterObjects, Linq to SQL, Entity Framework 1, and finally Entity Framework 4.
While each of these evolved the state of the art in data access, and some even did a reasonable job of generating code for your data layer, patterns of application development remained basically the same, and we as developers continued to write lots of code.
In mid-2007, the world economy began to struggle. Many things contributed to this global slowdown, but the impact on business and information technology (IT) professionals worldwide has been pretty consistent. We have been called upon to do more with less and help the business be more efficient. At a time when many teams and groups are struggling to prove their value to their business, we as IT professionals and developers have a unique opportunity. We can make the business more efficient and more effective. The key to success in this financial climate is to do things faster, better, and cheaper. Simply put, we need to write less code. Let’s get started.
Microsoft describes Visual Studio LightSwitch as “The simplest way to create business applications for the desktop and for the cloud.” Lightswitch was designed with the following goals in mind:
Simplified development
Speed to solution
Flexibility for today and tomorrow
We started this chapter with a bold promise: to help developers recover the productivity that we all said farewell to when we committed to SharePoint. Now we’ll back that up by talking more about how the design goals mentioned are realized in the product, and we’ll begin walking through the construction of our solution.
In addition to improving our productivity, we will also improve the support of your SharePoint farm. Rather than extending SharePoint to build our application, we talk to SharePoint only over published web service APIs. Deployment of your application can be done without impacting your SharePoint farm, simplifying the server administration skills required. By running our application code outside of SharePoint, we improve performance, stability, and make our upgrade to the next version of SharePoint seamless.
Get Developing Business Intelligence Apps for SharePoint now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
