There seems to have a buzz around the Lightswitch application framework.
Reading some posts/forums/articles and listening to a video provdided some answers, but raised some others.
Extensibility?
Is there several hooks to override or extend features?
Modularity? Can MEF/Prism be integrated? Is there a concept of dynamic modules that can be loaded at runtime?
Localizable? Any special features about localization in different languages?
Versionnable? Any concept of version so simultaneous version can co-exist?
Abstraction? The connection to data source can be abstracted and replaced?
Testability? Are the different components unit testable in an automated way? Easy or difficult to achieve?
Cross-cutting / NFR ? Any hooks so we can plug NFR code? (logging, caching, audit, secuity )
Is this a solid framework to build some PAAS application over?
Let me give you my 2 cents based on an eval I just did:
Extensibility
You can of course add custom controls and apparently there will be a published extensability API.
Modularity
No. Lightswitch is not a code generator, it abstracts out implementation of the UI.
Localizable
Did not see anything, but I imagine this will occur in stages.
Versionnable?
You could TFS the Lightswitch project, but if you mean versioning from an execution standpoint ... it's as simple as deploying a new version of the app to the server. The client will check for updates on run and install as necessary from what I understand.
Abstraction
Yes, if you abstract it at the WCF RIA Services layer which is very easy to do.
Testability
Business rules can be implemented at the RIA Services layer so testing there should be a snap, but if you rely heavily on rules driven through the UI you will have to use another UI-based testing tool.
Cross-cutting / NFR
If you focus on getting the RIA Services tier of the app to be the central location for business rules and let the UI just focus on user experience you won't run into much overlap. I think Lightswitch is a good client for many solutions, but the core power of it is using it as a client for RIA Services which itself is not dependent on Lightswitch by any stretch.
I hope I at least provided some useful insight.
Extensibility? When the built-in LS controls don't allow you to do what you need, you can use just about any Silverlight control (including 3rd party controls), or create your own custom Silverlight controls. There is a little more work to do than using LS controls, because the LS controls have some extra "smarts" built into them, so you can just drop them on a screen, bind, & use them. There are also extensibility points built into the framework that allows you to create your own "extensions" (shells, controls, themes etc).
Modularity? LS already uses MEF under the covers, so it's quite possible that it may be able to be leveraged further in the future. LS does generate code, but for itself, not for external consumption. There is an excellent article, however, by Microsoft's Eric Erhardt
http://blogs.msdn.com/b/lightswitch/archive/2011/04/08/how-do-i-display-a-chart-built-on-aggregated-data-eric-erhardt.aspx
that shows how to reuse the data model that LS constructs (in Eric's case, he uses it to create a RIA service that aggregates data for presentation in a chart control).
Localizable? I don't believe there are currently any built-in localisation features.
Versionable? For a web-based app, if the data schema didn't change, I don't see why you couldn't publish separate versions, but desktop (OOB) apps are click-once apps & are therefore governed by that technology.
Abstraction? If you were to create a RIA service for your data source, you could abstract away the implementation details.
Testability? Unfortunately, V1 was not written with "testability" in mind. If you extract out your business logic into Silverlight class libraries (for use on the client, or full .NET class libraries for use on the server), you can unit test that logic, but the code that you write in an LS application itself is not really unit-testable at this point in time.
Related
We're starting to develop a new Silverlight LOB application where the DataAccess will not be based on EF, rather our own DAL code (for legacy and other not related reasons).
We are currently debating whether to use RIA Services or simple WCF Services as the Silverlight's facade layer.
The options:
RIA Services and generated code: RIA Services will automagically create proxy classes of our Domain Model and DomainServices in our Silverlight project.
This will mean that our services will need to inherit from the DomainService class, and will require much work and workarounds to allow our custom model to be serialized normally (since we dont use EF)
WCF And shared libraries: We'll create a DomainModel library that will be shared between both Silverlight and our server code (as offered here) giving us more control as to how our domain classes look, and how they are seen on Silverlight, and our services would remain clean as WCF doesnt require us to use any base class and give us much more power over how our services are exposed.
So the question is - given that we dont use EF, what are the pro's to RIA Services, and what are the con's of using WCF and shared domain?
I have reasonable real-life experience with both technologies.
The main pros and cons in my perspective:
RIA Services
Pro: Development is (much) faster, even without using entity framework. You can create ViewModels, maybe mapping them with AutoMapper, and specify the attributes needed for validation / data entry / relationships. This is good practice even when using entity framework.
Con: A lot of overhead.
Con: Performance degrades when sending larger amounts of data (something like > 100 objects)
WCF and Shared Libraries
Pro: Performance is relatively excellent
Con: Development time / maintainability is not as good as RIA Services.
Con: Cannot use databinding as well without DomainDataSource (even when using MVVM).
Update
For the data-binding part: RIA Services allows for the DomainDataSource control in Silverlight. This enables easy (async) loading with bindable properties for its state (Busy etc.) which makes it easy to do loading animations and general improvements on user experience. This can of course be done without this control, but it helps.
For the RIA services performance, I cannot seem to find the example (someone here said they lost a few months of development time rewriting domain services to conventional WCF services because of the response time that could not be met).
One more note about a Silverlight (Business Application): try zooming your browser in to 110% or 90%, some arbitrary percentage. The fonts / components will get blurred because of way the rendering works. I have confirmed this on multiple machines/configurations and have not found a fix / work around for this. Snapping to device pixels does not help here at all.
Also before you make a decision, it's probably smart to also consider MVC3, with JQuery and HTML5 as an option for your solution. The HTML layout system might not be as good as Silverlight, but there are advantages like cross platform and mobile support.
I'm confused about the architectures which we can use to develop a business application with WPF 4.0 and EF 4.0 technologies.
My first choice was a traditional N-tier architecture contains: UI, Business Logic Layer & Data Access Layer with a disconnected behavior.
In this way I create 3 project for each layer and another project for my Entities/DTOs (Each layer is an assembly). Each layer references only to it's upper and lower layers (That is: UI can see the BLL but can't see the DAL). But all layers have access to the Entity/DTOs assembly for communication purposes.
The problem starts when I want to create a simple CRUD form with a DataGrid for example. The BLL disposes the DataContext of the DAL when returns an Entity/DTO, this is the reason that forced me to use STEs. But yet there are several problems. For example I should call "StartTracking" method for each entity returned from BLL to the UI. In short, I don't sure about this pattern reliability or I think I have to forget about automatic handled CRUD forms.
I use the repository model in my DAL layer but when I search about the repository pattern I find it different. It seems that it's not bad to reference to both of the DAL/Repository and the BLL/Services(Not WCF nor WebServices) layers from the UI and thus we can have a connected environment (Without using STEs).
I see an example in which we can get a person from repository but do something on it using BLL or services:
UI CODE:
var person = new PersonRepository().GetPerson(10);
Bll.Salary.PaySalary(person);
-or-
var person = new PersonRepository().GetPerson(10);
Bll.Person.MarkAsAbsent(person);
Or something like that...
With this pattern we can send the Entities/DTOs to the UI in a connected way while the DataContext is alive.
I don't know if I understand the way of using the repository pattern in big projects. I think it's not clear to naming the BLL or services classes and methods in this way. More over the developers might be confused about where to use the repository methods or BLL/service methods or about where to create the methods (in repositories or BLL/service).
I prefer the N-Tier architecture using a good approach to track the Entities/DTOs changes automatically like STEs.
Would you please recommend the best pattern in such situations or/and reference me to some good books or documents about that.
I put together a sample app that may help with some of your questions. You can review the presentation notes and the sample via my blog post here:
http://blog.alner.net/archive/0001/01/01/wpf_ef_4_sig_presentation_2010.aspx
The sample shows using STEs and includes some helpers to make the Entity Framework STEs work better in a desktop client app.
Repositories are there to hide the details of how you get the data. The idea is that you could swap the implementation of a repository from one that uses a local database, to one that uses a remote web service without the upper layers knowing about it.
Maybe the article Architecture for WPF applications is any help for you.
You might have a look at the BookLibrary sample application of the WPF Application Framework (WAF) as well. It shows a WPF MVVM application together with the Entity Framework applying the described architecture.
I'm starting to jump in to WP7 development and I have a few questions. My current background/experience is with ASP.NET. I'm new to Silverlight as a whole, so I have some questions regarding the architectural design of the application. I don't have experience with MVC, and it appears that Silverlight is based off of it. Is that true? To my original question:
Once the new developer tools come out, the app will have a SQL CE back end that, as a future release, will sync with SQL Azure. I'd also like to provide a web based application that performs the same functions, and interacts with the Azure database. I'm wondering how I should structure the app to minimize any code duplication.
I was thinking of using a generic n-tier architecture. UI > Business Layer > DAL (LinqToSql) > Sql. These classes could get re-used on the web too.
Silverlight is not really based on MVC. In fact, you can implement any architectural pattern as long as you fully understand its functionality. Most people prefer MVVM, which is similar to MVC, the only main difference is that the controller is replaced by the ViewModel that plays the role of an intermediary data link between the model and the view.
With the release of Mango, you will indeed have access to SQLCE. In your case, since you are planning on using specific interoperability layers, I would recommend building both applications in Silverlight with an intermediary web service that will communicate with the data storage (in your case it will be Azure). You win in two points:
You are using Silverlight, which means that you can use a similar codebase (with platform adjustments, of course) to deliver the same functionality.
The web service is app-independent. Therefore if you ever decide to build, let's say, an iOS application, you will be able to use the same communication layer without major changes.
It's my first question on SO. I know that there were many topics on Silverlight and architecture but didn't find answers that satisfies me. I'm ASP.NET MVC developer and are used to work on architectures built with the best practices (loose coupling with DI, etc.)
Now I'm faced to the new Silverlight 4 project and would like to be sure I'm doing the best choices as I'm not experienced. Main features required by the applications are as follows :
use existing SQL Server Database but with possibility to move to the cloud.
using EF4 for the data acess with SQL Server.
exitensibility : adding new modules without changing the main host.
loose coupling.
I was looking at different webcasts (Taulty, etc.), blogs about Silverlight and came up with the following architecture.
EF 4 for data access (as specified with the requirements)
WCF RIA Services for mid-tiers controling access to data for queries and enabling end-to-end support for data validation, authentication and roles.
MEF Support for enabling modules.
Unity 2.0 for DI.
The problem is that I don't know how to define a reliable architecture where all these elements play well together. Should I use a framework instead like Prism or Caliburn? But for now I'm not sure what scenarios they support.
What's the best usages for Unity in Silverlight ? I used to use IoC in ASP.NET MVC for loos coupling and other things like interception for audit logging. It seems that for Silverlight Unity doesn't support Interception. I would like to use it to enable loose coupling and to enable to move to the cloud if needed.
Thanks in advance for your help.
Best practice in Silverlight is actually (IMO) a bit a myth. By definition "Best Practice" refers to practices that generate the best results overall (quick to market, fast iteration of versions, low bug count, etc). However Silverlight 4 isn't even in production yet so its not actually possible to pin point what ultimately has turned out to be "Best Practice.
On top of that Silverlight itself and the technologies that surround it have been very fluid and and are very new. With that in mind here is my 2 pence.
EF and WCF RIA Services are most definitely going to figure in your architecture if you are build a LOB app. (Although NHibernate instead of EF may be worth a look, I tend to bias to MS components unless there is something else that knocks it out of the park).
MEF is most definitely worth further investigation if you are into DI. Its this area which is most in flux right now. I wouldn't be surprised to see Unity and Prism evolve to make greater use of MEF to deliver their various patterns. MEF is particularly good the loose coupling of which you speak.
I'm considering using Silverlight for a business type application which will contain probably a dozen or so screens. The screens will contain data entry forms with edit fields, grids, lookups, calendars, etc. Typical business application type screens. I want this to run in the browser but don't want to mess with HTML, JavaScript, CSS etc. Is Silverlight 3 appropriate for this type of application? Can someone build professional level business type apps with Silverlight 3?
#Randy Minder,
Glad to hear that you want to use silverlight 3 for line of business application.
I used to develop line of business applications in ASP.NET combined with javascript/AJAX. I am currently developing my first silverlight 3 line of business application and found silverlight is better in few departments. The following are the Pro/Cons observed by me PERSONALLY.
Pros
Layout/Styling(CSS)
XAML + silverlight 3 styling is very flexible and less cluttered when compared to CSS. I am not a designer and I hate having to deal with CSS. But in the case of silverlight, I really enjoyed creating the mockup,layout & styling. The end result is awesome. This is the first application that I developed has decent & consistent look & feel. I hope you will also find silverlight xaml to be easier to deal with.
Rich Interaction & Language support
I used to use Ajax, javascript for creating rich interaction experiences like populating some data dynamically when user interacts with UI. Writing some complex UI logic in Javascript is daunting. Though there are some nice javascript libraries like Jquery, I think writing UI complex logic in C#/VB.NET/F# is much easier than to write it in javascript. Dealing with rich interactive controls in silverlight is much easier than with javascript/ ajax controls. Writing server communication code with WCF or WCF RIA service is far easier than with ajax calls.
Browser compatibility
Each browser is different from another in one or the other way, like some browser supports something and others dont. Having to deal with browser differences in javascript is also a pain. Silverlight being a plugin doesn't have to deal with browser differences. No problems dealing with layout engine differences too.
Animations/multimedia
Ofcourse with line of business applications we will not use toooo much of animations/multimedia. However we can use small animations like menu popup, sliding controls, fading transitions for when data changes etc. These are very easy to implement in silverlight than with asp.net/javascript
Validation
Validation support in silverlight is awesome you can write more validation logic in less time.
Popup messages
Popup messages are very clumsy to deal in ASP.NET and sometimes I need to store some information in hidden fields to feed text for popup messages. Hidden fields are used as javascript & ASP.NET interaction components which are difficult to maintain and end up with more code.
Good separation of presentation & model
Though you can separate these layers in ASP.NET also, silverlight enforces this by design which is good. In my team there are few developers who dont want to put effort on separation of the layers. Unfortunately they are the seniors in age and decision makers. I always hate to deal with their spaghetti code. Not to say that I am a better developer than them, I always put some effort to separate the concerns and try to learn how to manage my code. ASP.NET webforms doesnt enforce separation of presentation & model by design. Where as silverlight enforces this by design and my life became easier.
Cons
Clipboard
Users are very much used to copy the content available on ASP.NET/HTML page. Most of the silverlight 3 controls doesnt support clipboard out of the box. The only control I know that supports out of the box is textbox.
Database Communication
Database communication in ASP.NET is easier & direct communication is possible. However silverlight being client side technology it doesnt have direct access to database and a necessity of creating an additional tier is mandatory. Though WCF RIA services make the development of this additional tier easier, still WCF RIA services is in beta as of now. Though I am mentioning it as disadvantage, I did not really feel it is as REAL disadvantage because creating a WCF service is not that difficult.
Client side resource usage
Though cost of hardware reduced alot,client side hardware resources are not unlimited when compared to server side. At my work place, though PC provided have decent configuration, most of the users open lot of applications simultaneously which is required to accomplish their day to day tasks. Silverlight uses client side CPU/memory. Some of my users are complaining that the application I developed is using more CPU/memory than the asp.net equivalent. So if your users have slower PCs, consider ASP.NET or design your silverlight application more carefully.
One may say installing silverlight plugin as disadvantage, I did not face the problem because my application is a intranet application and all users installed silverlight with a single email request.
These are MY experiences with silverlight 3. The only major issue I faced was clipboard support in silverlight, I hope MSFT will address this soon.
All in all, silverlight ROCKS!!! Silverlight 3 is ready for enterprise and if you can wait for few more months Silverlight 4 will be released which has even better support for line of business applications. I dont want to develop ASP.NET applications anymore, that doesnt mean that I will quit using ASP.NET, I will use it only when necessary. I fell in love with silverlight and for a good reason. Designing part of the website is the one I used to hate most but with silverlight designing became one of my favorites.
I hope that silverlight 3 will help you in your decision making.
Absolutely. Take a look at this post about the Vancouver Olympics:
http://csharperimage.jeremylikness.com/2010/02/vancouver-olympics-howd-we-do-that.html
That's just one example of a business application in the "real world" being used to drive a massively complex operation. I posted that just to draw attention to the "business" side of Silverlight, but be sure to click the link to the original post to see the other partners and contributions to the project.
I've been building enterprise/business applications with Silverlight for over a year now. So the answer is an emphatic "Yes, you can" and "Yes, it's been done" and "Yes, it's been done on a large scale with large companies, and very successfully."
I agree #Jeremy. Make sure to use RIA Services with Silverlight , You will get a very manageable/maintainable application. Even one more benefit is that you can make the SL app Out of browser too.