I'm just trying to wrap my head around this concept. I have written a couple different Web APIs but they have always been consumed by a website and interacted via JSON. I have a question about how to structure the implementation when the Web API will be consumed by a windows service.
In this case there is already an existing Database so I want to use Entity Framework's Database First approach.
I create a Class Library project for the models and use Entity Framework to look at the existing database and generate all of the required classes.
Then I create a Web API Project and add my Class Library with all of the models to it. Up to this point I am good.
My question is when I go to build the Windows Service that will interact with the Web API, how do I access the classes from my Class Library model project? I know I could add that project to my windows service but that doesn't seem like the correct approach because that would pretty much by-pass the Web API.
I guess my question is if I want to create and pass an Employee object to my Web API (so it can insert it into the database) from my windows Service, how does the windows service get the Employee object without adding the Class Library to the Windows service project?
In an n-tier solution you don't pass domain objects across physical boundaries, but you implement data-transfer objects (DTO) that will only hold the required info by the consumer/caller.
Usually you're going to created a shared library that will have the whole data-transfer objects and this will be referenced both by the server and the client.
After that, it's all about using a JSON serializer in order to serialize and/or deserialize your data-transfer objects.
Domain objects will be always mapped to data-transfer objects because these are lighter than a full object. Make yourself a question: if the consumer only requires the name and the second name of someone, why you need to send more data over the wire?
In addition, it's important to avoid server dependencies in client applications and services.
Some useful tips:
Learn what's a DTO: http://en.wikipedia.org/wiki/Data_transfer_object and http://martinfowler.com/eaaCatalog/dataTransferObject.html
Check AutoMapper and how can save you time in order to map domain objects to data-transfer objects: http://automapper.org/
Normally you create exra model classes that are used for the Web API. Those model classes often contain only a subset of the data of the entities. Furthermore, this distinction allows you to create truly RESTful APIs.
Inside your Web APIs controller classes the mapping between Model and Entity happens.
The windows service only referenes the project with the Model classes but not that with the Entity classes.
Related
We have one old application that is developed using asp.net web forms and asmx services. While developing that developer have created one class library with data objects and it is referenced both in Service layer and as well as client layer and to avoid the Data conversion while passing data from service to client vice versa they have modified service proxies (reference.cs) manually so whenever we update the service reference we have to go to service proxies and remove the data objects that is been generated by wsdl.
Now we are in the process of converting those ASMX services to WCF and we don’t want to do manual editions in service proxies like earlier so I have to build some kind of data conversion methods to transfer data from data contract objects to UI Models and vice versa.
Can anyone advise me what would be the better approach to achieve above? We have many complex class objects(approximately 3 to 4 level deep).
I have tried AUTOMAPPER to do but Automapper is trying to map values to **.specified properties that are generated by service proxies and i have approximately 20-30 properties in classes mapping logic becoming very huge.
I don't know very much of WCF...
I want to do a clean job to serve entities on client side using DataContracts. Imagine two DataContracts "System" and "Building": "System" may have many "Buildings" and "Building" may have many "Systems". So, we have a many-to-many relationship between them.
In service contract model, "System" have a "Buildings" property that is a collection. "Building" also have a collection of "Systems".
The WCF uses DataSets for the underlying data access (with stored procedures for CRUD) and I have a table between SYSTEM and BUILDING representing the relationship.
So, how can I implement this scenario cleanly? I want the clients to be able to get a simple representation of "Buildings" in "System", for example, I could use:
system = GetSystem(id);
foreach (Building building in system.Buildings) {
// do whatever with each buildings...
}
Thank you!
I think this question is too broad to cover in full detail, but I can give you a few pointers to get you started.
Forget about WCF and build the Data Access Layer (DAL). This should be a library which contains code to query the database and return strongly typed objects. This library might contain a method called GetBuildings() which returns a list of Building objects. The library might work with DataSets (and other database specific types), but should not expose DataSets to external callers.
Now that you have a library which can be used to get data from the database, write the WCF service. Code in the service component should call into the DAL and turn that information into DataContract objects to be sent over the web service boundary. Don't try to represent all your data in the DataContract objects - you want your data packets to be relatively small, so don't include information that isn't required. Balance this with trying to make as few web service calls as possible. In designing your DataContract classes, consider what the client application will be doing with the data.
Write the Service Client component. This is code which makes calls to the WCF Service, and turns that information into Entity objects.
The final (and most rewarding step) is to write the client application logic. Now you have another set off issues to confront about how you will structure client code (I recommend using MVVM). The client application should call into the Service Client component, and use the data to meet the requirements of your application.
By following the above 4 steps, you should end up with:
A Data Access Layer that talks to the database.
A Service Layer, which knows nothing about the database but is able to fetch data from the Data Access Layer.
A Service Client layer, which knows nothing about databases but knows how to fetch data from the Service Layer.
Application code, which knows nothing about databases or web services, but calls into the Service Client layer to get data and presents the data to a User Interface.
Everyone will do this differently, but the main thing is to separate concerns by using a layered architecture.
I'm building a Silverlight app that I want to be hosted in Azure and use Azure table storage.
I have a class that represents the main data entity, ExpenseInfo. It has many data annotations for RIA validation, such as [Required].
I am following this tutorial to set up the REST service for access from SL. It wants there to be a class in my web role for data serialization. This class would contain all the same data as ExpenseInfo.
So, where do I want ExpenseInfo to be? Do I want separate classes in each project? Put it in one project, and instantiate it in both? Is it weird to have a class with all those data annotations in the server side web role?
Thanks, I'm new to SL and Azure.
The pattern you're looking for here is the Data Transfer Object (DTO) pattern. Here's a good article on the pros and cons of that pattern. Personally, I don't mind the additional classes that a DTO and/or and Adapter pattern brings (you will see adapter type patterns used all over the place, MVVM is a hot one right now). I have a strong dislike for sharing business logic in assemblies across a trust boundary, so I generally use DTO/Adapter in my architectures.
I have a fairly clean ASP.NET MVC project structure. However, I'm struggling on how to organize the mass of classes which are DTOs (data transfer objects), e.g. just to encapsulate post data from forms (viewmodels) but don't represent full domain objects or anything near that yet; and then the many "result" objects I have which communicate complex result information from my service layer back to the controller. Where do you stuff these/how do you organize them? I have one folder with well over 60 classes now and it's getting cluttered. Appreciate suggestions!
Domain objects should live in a separate Domain Model library. Anything that supports the Domain Model in an framework-neutral way (e.g. no references to ASP.NET MVC, WCF, WPF etc.) belongs in the Domain Model.
Classes that perform translation between the Domain Model and the specific interface framework (ASP.NET MVC in your case) belongs in that particular project (your ASP.NET MVC project).
You can have your mappers etc. in a separate Mappers folder, but personally, I think it is much more valuable to structure code along features instead of infrastructure.
I use <CompanyName>.<ProjectName>.Core to store all project specific classes which are not strictly pertaining to the particular project interface that I am writing. So DTOs, DAOs, other project-specific classes are all in there.
I also use <CompanyName>.<DotNetLibraryNamespace> to store general purpose classes that could be reused across projects, and are not specific to this project domain. For example, string manipulation classes could go in the <CompanyName>.Text namespace. I always mirror the .net namespace structure names so that anyone that uses the .net class library has an easy time finding my stuff.
I created a new solution with 3 projects:
My "Client" is a ASP.Net Web Application. This should display the information.
My Businesslayer should have all logic in it, it's designed as a normal class libery.
My "Server" is a WebService. This connect via Linq to the database and get the Information.
Now only my Server knows Linq and knows the Database (how it should be).
But how can I give Linq Objects throug the WebService to my Business and my WebApp Layer to use it There?
For my understand there must be a way, because I have e.g. a complete user object with all needed Information with Linq, so I don't must create a own one, must I?
Linq should be covered as well as database. Your business-logic layer and server should better have common core objects used in client-server calls: this also will provide you easy means to add some additional info that is not stored in DB (if needed in future).
I would recommend you to create internal classes corresponds to the linq entities and expose those objects through the web service instead. Then you create mapping methods within the service application to map between those types.