I have been dabbling in WCF RIA with Silverlight for the past few weeks and I am finding it very difficult to generate well-designed software using it. My impression is that it's a tool that's best used for "rapid application development", prototyping and fancy-looking demonstrations.
As an example, to make the most of RIA I find you pretty much have to take a dependency on your data model from end to end. The best-sounding features of WCF RIA (like end-to-end validation and EF integration) require you to present your Entity Framework data model pretty much as-is, all the way down into your presentation layer. This precludes designing your software using a Service Layer pattern, data mappers or DTO's. I also find myself struggling (so far to no avail) to create an application with a true Domain Model due to limitations in EF.
The code generation stuff is nice and I could see it saving me time, except that it doesn't support such basic scenarios as many-to-many relationships. This causes me to have to expose even more of my database implementation details through EF by exposing the intermediate foreign key table.
On top of these issues, WCF RIA is notoriously almost impossible to test. DomainContext classes are not hidden behind interfaces and doing so is extremely difficult due to change tracking and other subtleties. In every single case I have seen in the wild, ViewModels end up taking direct dependencies on the DomainContext implementation. Even when this dependency is constructor-injected it's meaningless because it can't reasonably be mocked.
So I guess my question is two-fold: Does WCF RIA enforce bad design? If so, are there any reasonable workarounds that don't end up with me losing most of the advantages of the platform? And if not, can someone point me to some literature that shows how to generate good designs based on tried-and-true patterns using WCF RIA?
You might re-phrase the question as "Can I have my cake and eat it?".
Having been coding for some 30+ years I have seen this cycle many times:-
3rd Generation Language is too flexiable we are repeating ourselves doing the same things over. What we need is 4th generation language or framework the cuts out all this repeatition.
4th Generation Language or framework is too restrictive it forces me to find ugly workarounds and "enforces bad design" in my specific project. What we need is a more flexiable lower level language that lets us do exactly what we want.
Yet another 3rd Generation Language is too flexiable .... cycle repeats.
Tools such as RIA, Lightswitch, WebMatrix etc are in the 4th Generation camp. They by design enforce a specific way to doing certain tasks in order to eliminate repeation and to allow developers bang out working stuff quickly. Developers trade ideal design for speed of developement. This tradeoff is as old computing itself.
So to answer your question, no you can't have your cake and eat it. You either do things their way and use the RIA WCF service or you do things your way and create your own
WCF services. There is some middle ground (as always) where you can use some RIA WCF then jump through hoops making it do what you want.
BTW, EF does offer considerable abstraction (albeit with a lot effort) between the model it ends up presenting and your actual Database schema. It does for example allow you to present a many-to-many relationship without an intermediatory class.
The answer to this question is "No". It doesn't enforce "bad design". It's just a specific tool in your toolbox and it's designed to solve a particular problem. You sound like someone who is trying to take a hammer and use it to drill a hole, and saying, "Why doesn't this thing make a nice hole in my wall?" Ummm.. Because it's a hammer man. It's designed for a different job...
A lot of our skills as developers is in figuring out the right tool to use for the job. Silverlight and RIA have their uses, but they are not a magic silver bullet.
I think you're looking at the technology with the wrong goals in mind. And I say this as a guy who is a big fan of TDD, MVC, etc. I've written my share of apps that use DTO's, Repositories, layers, abstractions, etc... I've also written quite a bit of Silverlight and RIA in the past few months.
Anthony said it well: Silverlight and RIA are designed to "eliminate repeation and to allow developers bang out working stuff quickly." I don't think Silverlight and RIA are desgined for giant enterprise apps with loads of business logic tucked into the VM - something where you need unit testing and TDD to drive the process... This is the wrong tool for THAT job.
I decided to look at some of my ViewModels in some recent projects in Silverlight. Here's what I found: Everything I'm doing in the VM is pretty much delegating to something Silverlight already does for me: databinding, observing property changes, querying data contexts, saving changes to a data context, validating entities and notifying the GUI, etc.
Silverlight and RIA already do these tasks for me. I am just delegating calls! If I were to write a unit test, I'd be testing Silverlight and RIA - not my domain logic! I don't need to test the framework - I assume MS knows what they're doing.
If you have enough complexity to warrant DTO's, data mappers, service layers, etc... Then you probably need to think about something other than Silverlight and RIA. Know what I'm saying?
The right tool for the job man. Choose the right tools.
Related
I'm building a silverlight line of business application in silverlight 4 using RIA services currently and i'm finding RIA services to be more and more of a pain everyday..
A lot of the database interaction in this application doesn't follow the usual CRUD pattern and some of the data just doesn't "fit" with the RIA services style of doing things..
Even more importantly it doesn't fit the way my brain thinks about web services!
(I think that abstraction often gets in the way of the business problem you're trying to solve)
It's got to a point where a scary chunk of the code base is workarounds for the object context and spoofing ID's to create some kind of unique key etc..
I'd also like to swap out entity framework for rob conery's massive (he thinks the same way as me about abstraction, dynamic typing etc..)
Are there any alternatives which work using dynamic typing and JSON?
If not I may have to roll my own!
Have you looked at WCF Data Services?
http://msdn.microsoft.com/en-us/data/bb931106.aspx
You might also find that WCF Web APIs suits you better.
http://codebetter.com/glennblock/2010/11/01/wcf-web-apis-http-your-way/#0_undefined,0_
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've been playing around lately with Entity Framework, WCF RIA Services, and Silverlight 4. I'm impressed by how rapidly you can develop an application with these tools, and you get a lot "for free", such as the Silverlight UI automatically knowing about certain validations that are included as DataAnnotations on the EF model. However, it seems like in a large application it would be undesirable to have a dependency on EF pushed all the way through the entire application including the business logic and UI.
I know that you can use POCO / IPOCO with Entity Framework, and that is certainly an option for me. However, if you go that route, you lose some of the "automagic" stuff such as Silverlight being able to show model validations without any extra work.
How are people dealing with this? Do you give up some of the power and put interfaces in between the different layers in order to decouple the other layers from EF? Or do you give up on decoupling in order to allow for more rapid development? Is there some way to have my cake and eat it too that I'm not seeing?
My group is currently dealing with this exact issue. We came up with a decent compromise that everyone was happy with. Keep in mind that before it is all over with, projects become more complicated over time and maintainability is key. You also want to increase code reuse as much as possible so replacing your UI (or unit testing) is a minimized effort.
Given all this, we favored a well defined domain layer instead of pushing EF all the way through to the UI. This makes the model the heart of the application and doesn't force us to conform to the schema of our database. I know EF tries to abstract that away with its conceptual model, but we kept running into little gotchas that made it more and more difficult to rely on EF for the full stack. For instance, there really isn't a great place to put business logic with EF. We didn't want to put that stuff into Interceptors and we didn't want to put it in the UI. Sure, there might be a clever workaround for this, but we weren't liking the direction we were being pushed.
The compromise was to use EF but to keep it between the data store and the domain model. This way we still don't have to program against DataReaders, and we can leverage the benefits of self-tracking entities in the domain. We then expose basic WCF services (not RESTful) from our domain to our UIs.
To us, the extra validation work wasn't really THAT big a deal. Sure, our initial release takes a little more time, but the overall maintenance cycle doesn't take as long because we aren't finagling with the complexities of the framework.
First I'd like to make it clear, I'm not looking for a "my tech is better than yours" type of post; this is a real case scenario and I have been faced with this decision. With this in mind, let me explain:
We have a WinForms application. It started in the early .NET 1.0 but the first shipping version was using .NET 1.1. There are layers (like BusinessLayer.dll, Datalayer.dll, Framework.DLL, etc.) but at some point during the "long" development cycle of this application, the "presentation" layer (Win Forms) got infected with some code, thus the "separation between the code and the presentation with code behind" is some sort of myth.
Bad practices or whatever, the truth is that the application is there and it works.
Years passed and we had .NET 2.0, we slowly migrated and it mostly worked, had to change a few calls here and there. Last version did the same thing, but for .NET 3.5sp1. We needed some sort of Webservices thing, and decided to use WCF instead. It works fine.
But despite all these .NET upgrades, most of the application's codebase is still the same old rock and roll from 5 years ago. We use Gentle.NET (old and unmaintained now) for our dataobjects (it was a blessing 5 years ago!).
Our presentation layer, the winforms, are "nice looking" since we employ 90% of completely gdi+ custom controls. (whenever possible without having to hack the WinAPi). The application is touch based (i.e.: it makes use of the Ink but it doesn't rely on that), but the buttons, labels, etc, everything is "designed" to be used with a tactile device. (TabletPC or Touchscreen). Of course some users use keyboard/mouse.
With all that in mind, and with all this web2.0 and Internet fuzz (plus Jeff's posts ;) ), we are considering the possibility of rewriting the application but using a web technology.
The idea is obviously bringing more availability for our customers (they can use the system whenever/wherever they want), and less maintenance (we can upgrade and it is an instant upgrade for 'em all), etc. You know, the usual Internet vs WinApp thingy.
The problem is that given that this is the healthcare industry, not all of our customers might be willing to "move" their databases to our server/s, which is acceptable, and would force us to install a webserver/database server in their own servers so they have their own copy. Not a big problem (except we would have to update those manually but that's not an issue, given that we've been updating win32 apps for 5 years now!).
Now, back to the main "question".
The team has little Asp.NET experience, we did program a lot in ASP 2.0 (in 1999/2000) but that was a spaghetti of HTML+VBScript+CSS, so I don't think it counts. After all that experience (the Internet bubble!) we went back to VB6 then C#.NET 1x and you know the rest of the story. We're a small team of C# developers for WinForms. We've acquired some Linq To SQL Experience in our last .NET 3.5 ride, and we liked it. We felt it very natural and very "if we would have had this five years ago…" like.
Given all this, rewriting the application is not a "simple task" (not even if we wanted to do it in the already known C#.NET), it would take time and planning, but we could correct dozens of mistakes and with 5 years of experience working with the application, we now can say that we have a better idea of how the customers would like to use the software and what limitations we created (by ourselves) when we designed the current app.
All that "knowledge" of the application and the way the business works, could be applied to produce a much better application in terms of design and code and usability. Remember in .NET 1.1 we didn't even have generics! ;) (you'll see lots of ArrayList's hanging around here).
As an additional note, we use Crystal Reports (and, as usual, we hate it). We don't think the ink control is a "must" either. The HTML/CSS could be shaped to look the way we want it, although we're aware that HTML is not WinForms (and hence some things cannot be reproduced).
Do you think that planning this in MVC (or WebForms) would be too crazy?
I like the MVC (ruby on rails like) idea (I've never programmed in ruby beyond the basics of the book), so no one in our team is an expert, but we can always learn and read. It mustn't be "rocket science", must it?
I know that this whole question might be a little bit subjective, but would you replace an aging Winforms application with a new ASP/MVC/XXX web application? Do you have experience or have tried (and had success or failed) ?
Any insight in helping use better decide what to do will be appreciated.
Thanks in advance!
UPDATE: Thanks to all who responded, we'll evaluate whether this is a good move or not, it sure is a hell of work, but I am afraid the the desktop app is getting older (using old net 1.1 hacks) and tho it has been more or less working without problems in Vista and W7, I'm afraid a future update may break it.
Also, lots of "more or less core" parts of the application are exposing some badly designed ideas and we had to hack here and there to accomplish certain tasks. Part inexperience, part lack of 100% knowledge of how the business worked (and Customers not sure what they wanted).
A new application (in any form) would allow us to create a better foundation while retaining all the user knowledge.
But, it's a L O T of work :) So we'll consider all these options here.
As some of you have mentioned, maybe a thinner client and some (ab)use of WCF here and there might be more appropriate.
Once again, thanks to all!
It would be best to ditch all your efforts of reusing the desktop application code when you recreate the web app. Following are the reasons:
Web apps especially asp.net use a different model. For starters note http is stateless. Each time the browser talks to server you have to explicitly send the current content of all the controls on the current page. You would not have used such a model in your Windows application.
To decrease load on the network you want to optimize the size of viewstate and how frequent you make http requests. Again your existing window app does not have any such provisions.
Updating view. You might have different event handlers, threads and what not in your windows application to update the GUI in different scenarios. All of that will need to be replaced. Javascript is a totally different animal.
Security. When using a browser your access to the local disk is highly limited whereas you will take the same for granted in windows application. If there is any code in the windows app that requires local resources, then that is going to be a trouble spot for you.
I would recommend the following:
Verify if your current application has any local disk access requirements (e.g. read/write to local file etc).
As you write the different http modules or handlers, you can try leveraging some of the backend/ business logic part of the existing windows application.
Give some thought to what part of your application can become a web service.
It sounds like the application needs a lot of refactoring to clean it up. If you want to move to a web model, and have maximum reuse you will really need to do that. Before you move to a web model I think you need to understand if it will be possible to replicate your user interface in that model. Is it your unique selling point from a customer perspective? You want decisions like this to be user driven rather than purely technical decisions.
It sounds like your application is the perfect candidate for a thick client application, rather than the lowest common denominator web model.
Some things to consider:
How will the web interface impact the Tablet interaction?
What new customers will having a web version bring you?
Will existing customers abandon your product?
Do you have access to consultants or outside resource with the right skills to mentor you in web technology? If you don't you can rely on StackOverflow or other web resources to help. You need some good mentoring and guidance on the ground with you.
What happens if you start this effort and it takes much longer than you expect? You know the app but don't sound like you know the web. Past experience shows that massive rewrites like this can end in disaster (it never sounds so difficult at the start)
Can you possibly write new features in a web-based version?
Could you move to ClickOnce deployment to make the application easier to deploy to customers. One of the benefits of the web is easier (zero) deployment. Can you get closer to that?
Would it be easier to migrate to WPF and create a browser application with that?
Silverlight or Flex might be better options for creating a rich experience, and may be more approachable for WinForms developers. Is this a possibility?
It seems like your app. is one of those that works best as a desktop app. Though you want your users to be able to access your app. using a browser.
I would suggest refactoring as much as possible so that the GUI gets cleaner and don't have "code".
When you've done this, start developing a asp.net mvc app but keep your desktop app. You should be able to use all layers except the UI layer, making it easier/faster/... Now that mvc exists, I'd say webforms is more about letting non-web devs do web. But you know web, sort of, and you want control so mvc is the way to go.
We have a large suite of apps, most are C# 1.1, but at least 10 major ones are in VB6. We are undertaking a project to bring up the VB6 apps to .NET 3.5.
All the c# 1.1 apps are written using a traditional n-Tier approach. There isn't really any architecture/separation to the UI layer. Most of the code just responds to events and goes from there. I would say that from the point of maintainability, it's been pretty good and it's easy to follow code and come up to speed on new apps.
As we are porting VB6 apps, the initial thinking was that we should stick to the existing pattern (e.g. n-Tier).
I am wondering, whether it's worth it breaking the pattern and doing VB6 apps using teh MVP/MVC pattern? Are MVC/MVP winform apps really easier to maintain? I worked on a MVC-based project and did not feel that it was easier to maintain at all, but that's just one project.
What are some of the experiences and advice out there?
Dude, if something works for you, you guys are comfortable with it, and your team is up to specs with it. Why do you need to change?
MVC/MVP sounds good... Then why am I still working on n-Tier myself?
I think before you commit resources to actual development on this new way of programming... You should consider if it works for YOUR team.
If you are porting the VB6 apps vs. a full rewrite, I'd suggest to focus on your Pri 1 goal - to get asap to the .Net world. Just doing this would have quite a lot of benefits for your org.
Once you are there, you can evaluate whether it's benefitial to you to invest into rearchitecting these apps.
If you are doing full rewrite, I'd say take the plunge and go for MVP/MVVM patterned WPF apps. WPF willl give you nicer visuals. The MVP/MVVM pattern will give you unit testability for all layers, including the visual. I also assume that these apps are related, so chances are you might be able to actually reuse your models and views. (though, I might be wrong here)
It moves a thin layer of code you still probably have on the UI. I say thin, because from your description you probably have plenty of code elsewhere.
What this gives you is the ability to unit test that thin layer of code.
Update 1: I don't recommend to re architect while doing the upgrade, the extra effort is best expend on getting automated tests (unit/integration/system) - since you will have to be testing the upgrade works anyway. Once you have the tests in place, you can make gradual changes to the application with the comfort of having tests to back the changes.
MVC in particular does not exclude n-Tier architecture.
We also have ASP.NET 1.1 business application, and I find it a real nightmare to maintain. When event handlers do whatever they like, maybe tweak other controls, maybe call something in business logic, maybe talk directly to the database, it is only by chance that software works at all.
With MVC if used correctly you can see the way the data flows from the database to your UI and backwards. It makes it easier to track the errors if you got the unexpected behaviour.
At least, it is so with my own little project.
I'll make the point once again: whatever pattern you use, stick to the clear n-Tier architecture. 2-Tier or 3-Tier, just don't mess everything into a big interconnected ball.
"Change - that activity we engage in to give the allusion of progress." - Dilbert
Seriously though, just getting your development environment and deployment platforms up to .NET 3.51 is a big step in and of itself. I would recommend that things like security reviews and code walkthroughs should probably come before re-archecting the application.
MVC and MVVM are excellent paradimes, particulary in terms of testability. Don't forget about them, but perhaps you should consider a pilot project before full scale adoption?