I have to build a web application in Silverlight. This application is entirely data centric with SQLServer 2008 as the database.
What are different ways of handling this design problem? Someone told me RIAServices would be a great option, but I am not completely knowledgable of it.
One simple option I know of is creating WCFService and exposing the methods to perform the actions on the database object.
Any suggestions?
You answered your own question :).
3rd option ADO.NET dataservice. But RIAService is the #1 right now for n-tier LOB applications.
Related
I want to know if using Self Tacking Entities (in Entity Framework) is recommended with WCF services? If yes, then can you guide me to a tutorial which may guide how to do that?
Actually, I am going to develop a WPF application using Prism with MEF and MVVM. I have decided to use Entity Framework. I want suggestions and advices regarding this approach.
Any help will be appreciated.
I want to know if using Self Tacking Entities (in Entity Framework) is
recommended with WCF services?
It depends who you ask. If you ask MS they will tell you Yes because they simply don't have anything better to offer. STEs were response to this very old MS Connect suggestion. The problem is that EF itself has terrible bad support for merging changes between two entity graphs (you must do it completely yourselves) and developers working on MS platform (sometimes including me) share some common behaviors:
They are lazy to develop their own solution to problem and they expect some magic directly in APIs provided by MS.
Most of the time they are not trained / skilled / competent in the technology they have to use, because they have to move to a new one too often.
The only APIs they know are part of .NET Framework. They don't look for other options neither they compare features.
First two points are result of MS strategy where RAD become synonym for designer (or newly also T4 templates).
I share #Richard opinion about STEs. I would add one additional drawback of STEs - they move large datasets between participants. If you decide to get an entity graph from the server, change a single entity in the graph and push data back they will transfer again the whole graph. Transferring only changed entities results in fighting with STE's core logic. I'm also afraid that they track changes completely on per entity level instead of per property level. In case of modification to entities with large binary or string data it can result in transferring too much unneeded data between the service and the database and between the service and the client.
Anyway for a simple application with low data traffic and small entities they can do a good job and allow you building your application quickly but without strict separation of concerns. You will get entities from service and bind them directly to WPF UI and they will be able to track changes for you. Later you will push entities back to service and they will be able to persist changes. Your client and service will be tightly coupled but in some scenarios it can be good enough.
I would avoid self tracking entities in general - I blogged about it here.
Create your own DTOs and use them to manage the transfer of data - then biuold your POCO objects in the service and use them with entity framework for persistence
If you want self tracking then there is a slightly cleaner approach here
We are in the conceptual phase to create a relatively medium size enterprise business product application using Silver light 4.0, Entity Framework and WCF.
1. Is it adivceable to use Silverlight 4.0 for this enterprise business application development or should we go in for MVC.NET / ASP.NET?
2. We have planned to use REST based WCF service. How complex would it be to write the information back to the REST WCF service?
I appreciate and welcome your advice / suggestion. If you need any further details do let me know, i will be happy to share.
Thanks in advance.
If ASP.NET (MVC) and Silverlight are my only choices, I'd take Silverlight.
If you were to choose ASP.NET (alone), remember that MVC isn't your only option. While MVC 2 is the hot ticket on the block, so to speak, WebForms is still being advanced and actively developed and supported by Microsoft.
Also, if you're going to be using Silverlight, you'll be using web pages anyway (at least one) and it's certainly conceivable (possibly desirable) to compartmentalize it such that you can use both.
Having said that, I would honestly recommend WPF over Silverlight for enterprise development unless it's absolutely necessary for it to be cross-platform. It's what it was built for and allows you to completely unleash the capabilities of the OS, not the least of which being that it opens up every security option WCF offers.
As for your question about how easy it is to write information back to a REST WCF service, I suppose the answer to that is relative to how good a developer you are. :) Honestly, it's pretty easy though. Specifically, I'd look into WCF RIA services for that sort of thing.
For Line-of-business apps i will prefer Silverlight. but if you are going for SL4 them i think you should also consider this:
http://christopherdeweese.com/blog2/post/using-silverlight-4-to-browse-netflixs-odata-catalog
Microsoft recently introduced OData as an alternate to WCF. I haven't played much with OData but its easy to work on REST based services but full control over it. I think you should further investigate your options and consider OData as well.
Regards.
What are the improvements in vb.net compared to vb6 that make developing such an application easier?
I can think of a few:
ADO.NET is better than ADO for data access (and more options such as the Entity Framework, data repository blocks, LINqtoSQL)
better ability to structure your code for ease of maintenance because of better support for object oriented programming
better testability
overall a much better IDE
better handling of XML
richer set of interface choices: silverlight, WPF, WinForms, WebForms, ASP.NET MVC,
Web Client Software Factory
ASP.NET allows you to divide your interface code from your business logic much better by moving the logic into the code-behind file: better separation of concerns leades to easier and cheaper maintenance costs
WinForms has a much richer set of controls allowing you to build apps that are much easier for your users
better integration wilth other Microsoft products such as Sharepoint
This is by no means an exhaustive list. But it's at least a good starting point.
I switched to VB.Net because of LINQ. Everything else was a nice bonus. ^^
The ability to use the farking scroll wheel on my mouse in the IDE!
Sorry, had to vent on that one since I've recently been stuck in VB6 for maintenance on a legacy app.
I'm looking at new architecture for my site and was wondering if pairing NHibernate with a web service core is a good idea. What I want to do is make my webservice the core of my business, from the site front ends to the utilties I write. I'm trying to make all of my UIs completely ignorant of anything but my service API's.
In a simple strawman experiement, I'm running into issues with Serialzing my Iesi ISets....this is causing me to rethink the strategy altogether.
I know I could just develop a core Library (dll) and reference that in each of my applications, but maintaining that dll's version over a minimum of 6 applications seems like it's going to cause me much pain.
With NHibernate, what are the pro's and con's of those two approaches?
I see no problem in using NHibernate and webservices together - I just don't think it's a good idea to send the entities themselves over "to the other side".
A better approach is to use a set of DTOs that are made for the service - then you won't be running into issues like that of serializing unknown types and such.
You can use a library like AutoMapper to do the mapping from the entities to the DTOs.
There's a lot of stuff written about this, some of it:
http://martinfowler.com/bliki/FirstLaw.html
http://ayende.com/Blog/archive/2009/05/14/the-stripper-pattern.aspx
http://elegantcode.com/2008/04/27/dtos-or-serialized-domain-entities/
DTOs vs Serializing Persisted Entities
As a side note for the service it self, you could design wise use an approach like Davy Brion describes here: http://davybrion.com/blog/2009/11/requestresponse-service-layer-series/
I don't know NHibernate, but want to remind you that you should be using WCF for new web service development, unless you are stuck in the past (.NET 2.0). Microsoft now considers ASMX web services to be "legacy technology", and you can imagine what that means.
I am building a WCF application, using NHibernate for the persistence layer. A lot of documentation thats out there is about using NHibernate with ASP.NET applications. But very little on the best ways to manage NHibernate Sessions in a WCF application.
After reading up on Instance Management Techniques in WCF applications, I am going to use "per-call Services". Drawing parallel with ASP.NET, this is like opening NHibernate sessions on Application_BeginRequest and closing them on Application_EndRequest. Billy McCafferty's S#arp Architecture has a great example of doing this very elegantly. But I am finding it a little hard to use a similar concept in a WCF application.
Any code samples or pointers to blogs with examples, will be greatly appreciated.
http://www.igloocoder.com/archive/2009/04/23/wcf-and-nhibernate-redux.aspx -> https://igloocoder.net:8443/svn/IglooCommons/trunk/src/IglooCoder.Commons/WcfNhibernate/
I found another good example -
http://realfiction.net/go/133