What is the best method/technology to sharing the same data access layer between WPF, Silverlight, and ASP.NET?
I am using ADO.NET Entity framework, and was thinking of a creating a DAL using the Repository pattern.Then using the RIA Services as a dummy middle man to connect Silverlight and ASP.NET. Is this a solid plan or are there other better solutions out there?
One of the solutions I like to use is the following :
- Have a project storing only the entities (for example : Player, Game, Entity) with no reference to the database at all.
- Have a project implementing the repository pattern (Repository, Repository etc...)
- Use ADO.NET Entity Framework code first approach to map with the database (it creates a dynamic child object of your entities contain in your project, see ScottGu's blog for an explanation on how to use it)
Connecting Silverlight to your pattern can be done with Ria Services or classic WCF services. Usually I try to use WCF whenever possible as Ria Services is not really compliant with an MVVM development.
If you want to use WCF and share your DAL entities with Silverlight you can create a MyDal.Silverlight Silverlight class library project and add symbolic link instead of copies of every entities you will want to share with Silverlight. Then when you'll add a service reference with visual studio it will be smart enough to not create copies off Player, Game and User to you Silverlight project.
If you want to use Ria Services it will create copies of you entities anyway.
Hope that helps
John
RIA Services
RIA services will certainly take the burden off you for all the WCF plumbing. It has a few minor flaws (lack of certain data types), but there are workarounds for most problems.
The validation model (using attribute decoration and custom validators) is very strong and a great place to hang business rules.
RIA coexists happily with ASP.Net, so that is another plus. Behind the scenes it is just another WCF service. We are happily using RIA services with MVVM and Prism.
ADO.Net EF model
This is a tried and tested feature rich model. The only problems I have found related to many-to-many relationships. Again there are workarounds.
DAL
As RIA change sets are managed for you on anything, including POCO, this is the area that will need the most attention. It is considered "bad" to expose your EF model directly to RIA and that will certainly not insulate you from data changes.
I can't specifically recommend any one pattern yet (still experimenting), but make sure your choice is compatible with IQueryable. The paging feature and appending to Linq queries for server-side execution are features you do not want to lose!
Related
We've just entered the development phase of our project. We're trying to define the best long-term supportable architecture that we can while providing a service layer that other LOB applications can be bolted onto later. In the conceptual stage, an ESB seemed like the best bet, but there's no corporate standard ESB, and implementing one just for our project seems like taking a freight truck to the grocery store.
I did a little digging and found WCF RIA Services. Hey, perfect, just what I wanted. Sure, it's default state is for Silverlight, but it works with ASP.NET clients just as well. But then it seems like Microsoft is dumping RIA Services. So, what should I use instead? I don't want to implement a "new" technology here that is dead before our project gets started. I looked at Open RIA Services, but that seems to be hospice care for the technology more than anything else.
My goal of separating the App Logic/Persistence layer from the Presentation and Business Rules layers holds. We prefer to stay within the .NET ecosystem. So, what is Microsoft issuing to replace WCF RIA, if anything?
RIA is more about code generation...
What is WCF RIA services?
I think Microsoft is steering towards REST based services with their ASP.NET Web API...
http://www.asp.net/web-api
https://msdn.microsoft.com/en-us/library/hh833994(v=vs.108).aspx
In terms of client proxies for ASP.NET Web API, the primary means of consuming such services is in HTML Javascript...
http://www.w3schools.com/ajax/ajax_xmlhttprequest_send.asp
http://www.asp.net/web-api/overview/data/using-web-api-with-entity-framework/part-6
http://proudmonkey.azurewebsites.net/asp-net-5-jump-start-to-angularjs-with-mvc-6-web-api/
Maybe not the answer you wanted but anything else is probably not a path most will follow.
You could also look at SignalR...
http://www.asp.net/signalr/overview/getting-started
ServiceStack is one proprietary framework built on top of .Net that may fit to your needs, give it a look Here.
I have an application which is built in ASP.Net WebForms and Silverlight.
There is another WCF services application which is accessed by silverlight part of my application.
Now I have to Re create the whole application in an MVC Single Page Application(SPA) and of course the WCF one because now I would need Web API for that.
An initial solution comes into mind is to add a web api project into wcf services application and start creating web methods there and call wcf methods from there if that functionality was already there.
And for webform start a new spa with mvc project from scratch and use durandal or any other spa client framework(hell of coding).
Any useful solution/advise? as I am looking for simplicity.
I searched around and found some questions but really did not helped as they are about merging with existing apps.
Note: application is a large application with a lot of functionalities
You have to decide how confident your team is with client side frameworks. Development of Single page applications may not be easy in the beginning, but you will get used to it very quickly. It's very important to give your team the right training.
In my opinion, Durandal is the simpliest, most elegant and complete framework to build enterprise level SPAs. It is important to know how knockout, requre and durandal's router and composition work. For data centric application I would use breezejs to manipulate and cache data on the client side and request it from the server side. Breeze works best with Entity Framework on the server side, but it's not necessary. If you can use Entity Framework, it will simplify your development, because it can generate metadata of your database structure for breeze. If Entity Framework is not an option, metadata can be written by hand.
I would make server side as thin as possible. Serving data from your database using web api with ORM of your choice and some cshtml pages.
Durandal Get Started is a good place to start.
Durandal Auth is a very good template for enterprise level SPA. It may not suit you completely, but you can use it as a guidance to build different modules of your application.
Breeze samples I suggest you consider using breeze. There are good courses available on pluralsight.
Knockoutjs has good training on data-binding.
I want to know list of advantages of using Entity framework over data access layer.
My website is host in shared hosting and i don't have access to IIS
Considering that i am working shared hosting world, is it feasible to work with entity framework?
Microsoft has publicly stated that Entity Framework will be the preffered data access technology for the .NET platform. Given your experience I feel like Entity Framework would be a huge asset to your ability to rapidly develop applications. Shared hosting is completely irrelevant to the fact that you are using entity framework. Just make sure that the hosting company supports .Net 4 framework (or w/e framework version you work with).
Entity Framework is a data access layer. Specifically it's an Object Relational Mapper.
So it basically comes down to - do you want to write your own DAL? - or would you rather spend your time building out the Data Model, and then having Entity create your entities and classes, etc.. for you.
I'm working on building an application that's based on SOA. I have bunch of business services that I should make them available as components to another applications (so I'll use web services -SOAP-).
The application presentation layer is MVC.
1- Model: Contains DataBase methods (ORM is used).
2- Controller: Contains calls to the model methods as well as methods to handle simple view actions.
3- View: Contains rendering content only.
So, can you give me a simple scenario how can I combine web service with my MVC application, my suggestion is to separate the model as web services, is that right?
I'd tackle it this way: (YMMV)
Build a data tier assembly housing all your data access. Call it the DAL. It will contain all data access methods. This will enable re-use, but also allow for methods used by one application below. This is where your EF model can live.
Build 2 web projects: MVC and web services. Each will implement business logic to satisfy their respective requirements. They'd reference and call into the DAL as needed for data access. As you noted, they're both presentation-tier services. One has a user interface, the other is a communication endpoint for remote web service consumers.
Deploy both onto an application server as needed. Suggest creating 2 applications/sites in IIS - (i.e. "Web" and "WebServices"). This separation of applications ensures that one can be changed/downtimed/versioned without effecting the other.
The MVC project/app will still have its Models, Views and Controllers as per normal. The biggest change here is that the Models would be used only for ViewModels as needed. It would contain any business logic to satisfy the UI requirements. Its controller methods would call the appropriate DAL public methods as needed.
The web services project/app would be able to be changed independently as needed, while the data access would remain.
1) Place all your service operations behind an interface.
2) Consider using an Inversion of Control container to utilize dependency injection in your application. This allows you to mock your dependencies and unit test your controller logic more easily. Some examples are Windsor, Ninject, StructureMap.
3) Consider using strongly type view models for your views, instead of the objects that your ORM works with. You'll want to set up some mapping classes to help manage this, but a lot of the pain can be taken away by using something like AutoMapper.
Here's some good links on the subject:
How we do MVC – View models
ASP.NET MVC View Model Patterns
Never use web services for the sake of using web services: You should first have a problem that needs solving, and see that web services are the best solution to your problem. So depending on your need, web services can be used in a variety of different ways.
For example, since you say MVC is your presentation layer, you may want to insert web services as a layer between the Model and the Controller. Rather than invoking your model (data layer) directly, the Controller invokes your web services and provides a web-based front-end to the services that would otherwise be available via your SOAP API.
Another option is to make both your MVC front-end and the SOAP services access a common business/data logic layer, each providing their own "API" for the same back-end.
But again I emphasize: web services should not be used as solution in search of a problem. If it's not obvious to you where the web services should fit into your architecture, you are very likely better off without them.
I am starting a new project which will need a ASP.NET MVC 2.0 website, a Silverlight section and a Windows Phone 7 UI.
My plan was to use WCF RIA Services to create a set of services which would be used in all different UI projects. With the Silverlight project I would use the standard tool integration, the Windows Phone looks like it may have to be WCF Services exposed by the RIA Domain Services, but I'm not sure about the ASP.NET MVC website.
My initial thoughts I would simple reference the class library containing the Domain Services and use them directly. Could this be considered a viable approach to using RIA Domain Services in a ASP.NET MVC website?
Kind Regards
Michael
I know a long time has passed since this question was asked, but since I had to make such a decision, I might as well document it for the benefit of others.
I work in an environment where lots of legacy and new apps co-exist, with the legacy apps being phased out. So we've had to build interoperability between everything from MS Access, to web service end points in C#, VB, Web Forms, MVC 3, even Flex, Reporting Services...the list goes on.
One of the biggest pain points in a multiple-client scenario is the maintenance of interoperability over time. As data, requirements and delivery mechanisms change, keeping things smooth ends up taking a lot of resources.
My approach has been to create one and only one mechanism for reading a given source of data by defining 1) a model, 2) a serialization/deserialization layer and 3) a service layer. All projects that need to use XY_Data must use the XY_Service to get XY_Objects via the XY_Serializer. Direct db calls or stored procs, etc are allowed in the XY_Application. This allows me to drop in replacement DLLs (versioned) with bug fixes and upgrades without restarting anything. I hardly ever do a full publish.
So yes, what you're suggesting will work. I would recommend only that you rigorously enforce the single-source-of-truth and DRY policies both in your data and your APIs.