Ive been playing around with the entity framework with an idea for creating a web service to be consumed by an application in sharepoint that a 3rd party developer is creating. Basically i need to return a list of jobs e.g list based on some search criteria. I wanted to use the EF so i have something scalable however it seems returning POCO's from a web service is harder than i imagined it to be. Are web services and EF / POCO's meant to work together. Does anyone have any good examples or can point me to some.
Are web services and EF / POCO's meant to work together.
Yes. The only thing you must to ensure is to make your entities serializable - POCO entities can contain circular references which are not serializable by default.
What about consuming the web service? I read somewhere that the consumer has to reference the entity namespace to use the returned objects.
This is not true with POCOs. This is only true with Self tracking entities.
Related
My Question is about returning EF entity using WCF service. As wcf required Data Members for returning data. Solution i have to do mapping of entity to WCF data members which is quit hectic.
Is there possible solution which reduce my work effort. I tried EntityFramework with WCF - how to return EF entities but available solution have support for vs2010
only.
This is tricky question. You want to pass EF entities through WCF. This is bad in some way, because EF objects are burdened with additional data provided by EF (e.g. for change tracking purposes). The best way to pass objects through domains in your application is create DTO objects. To do that, you can develop additional mappings (with usage of T4 templates) that create this DTOs based on your existing EF entities.
Please bear with me as I am new to MVC and WCF and may be asking the wrong question.
I am trying to write a WCF service and an MVC web application over an existing project that contains entity, data and business layers. The MVC and WCF components would then replace an older web service and WebForms application which worked very diferently and did not use modern practices.
I see the need to generate DTO objects against all Entity objects and was wondering how we can generate them. Through reflection, digging into the DbContext or some other method.
Furthermore, I also want to generate repository partial classes minimizing the need to maintain hand-written code for a large data model.
How do large development teams do this?
I want to use SOA environment for my project. I have a several requirements:
1. Web site on Asp.Net MVC 4
2. CMS for the site - on Asp.Net MVC or Silverlight.
3. The mobile applications - iOS, Android, WP
4. Also, there are must be API for external services (pay terminal, web sites and other, mobile apps also can use this API)
Therefore, I want to use SOA. And I have one question.
The services coordinates the interaction between business objects and data access
objects by saving and retrieving business objects using DAOs (data access objects) to
and from the database. And, I must to convert entities to DTO and vice versa. I can use Autommaper for this, for example. But, I worry about performance.
For example, we have method in repository which return info about order. The Order have many FK to other tables. But, I need to only two tables. A generated sql contain many join for all references tables. Then we convert this order entity to DTO.
The question: how to or What I need to use for generating query that it will be lightweight and contains fields only needed for DTO? I must to use ExpressionTrees or something else, there are some examples or library?
Thanks and sorry for my English.
It looks like you need an ORM tool.
http://www.fluentnhibernate.org/ is good. If you want to stay with .NET you could use Entity Framework (but I'm not an expert in it).
Given that directly exposing linq to sql or entity framework classes over web services is a bad idea, how should I expose the data over a web service such as WCF?
It seems like I would have to create a parallel set of classes for the web service, and then marshal the data into those, which doesn't seem very elegant.
The web services will be custom, so something like RIA is not very useful in this case.
You can use the support for POCO (Plain Old CLR Objects) in EF 4 to expose the entity model as simple objects. The designer supports converting entity data model into POCO objects.
Specifically for WCF service scenario, you could also use the self tracking entities T4 template available in EF 4 when you try to add new item to the project.
I hope following link will be helpful to you
http://blogs.msdn.com/b/efdesign/archive/2010/03/10/poco-template-code-generation-options.aspx
http://blogs.msdn.com/b/adonet/archive/2010/01/25/walkthrough-poco-template-for-the-entity-framework.aspx
Generate POCO classes in different project to the project with Entity Framework model
Have you seen OData and WCF Data Services? Here is a great talk by ScottHa: http://www.hanselman.com/blog/ODataBasicsAtTheAZGroupsDayOfNETWithScottGu.aspx
OData, through WCF Data Services, works seamlessly with EF 4.
I am going to create a new asp.net web service (.NET framework 2.0), the functionality of the web service is to recieve xml input, perform the relevant operation (add/modify/delete) based on the input and return codes which indicates the status of the operation. I am planning to implement two layer architecture (Business layer and database layer) for this web service, could anyone advise whether this is the right structure or any other structure would perform well than this. Basically I need some inputs on designing the web service.
Thanks in advance.
Thanks,
Muru
The Domain Model should express the business logic in a way that is independent on boundary technologies such as WCF or ASP.NET web services.
This adds the requirement of a third layer:
Service
Domain Model
Data access
If you don't make a separate layer for the technology specific interfaces (Service), you might as well just make a single, monolithic application, because you wouldn't be able to reuse the business logic anyway.
While we're at it: use WCF, not ASMX, for web services.
I would write a web service using ASMX because it's easier to get your head around to start with.
Implement DAL by using ADO or LINQ (might be easier option since it does all the mapping for you and it's good to learn something new imo).
How are you going to call a web service? Did you consider how you will return status code? You can look into JavaScript and Ajax so that you can return custom objects to the client, or you could look into SOAP, which is xml based.
Can also recommend a good read - ASP.Net and Ajax: architecting web applications. Might give you a better idea on what options you have.
i always use the same model: service / business layer and a database layer.
When it comes to Visual studio, i have 4 or 5 projects:
1 with the webservice named project.webservice (which ONLY task it is to receive input and give that input to the layer that does the thinking (business layer), so testing is easyly done to the business layer
1 with the service layer named project.service which does the actual work (decide what the operation should be, call the right db methods etc)
1 with the database logic called project.datalayer which could be ADO.Net code or the Entity framework.
1 with the dataclasses called project.model. These classes are the ones returned by the ADO.Net code and used by the service and the webservice project. If i use a entity framework i normally skip this project, because the EF itself gives me dataclasses the EF generates. Sometimes clients don't want to use the EF dataclasses, then i create the project.model project and let the datalayer translate the EF dataclasses to project.model dataclasses
1 with the testproject named project.test
hop this helps,
Michel