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.
Related
I have a C# Winform application (.Net 3.5) which access a MSSQL server using typed DataSet objects.
currently, my whole application is working in one layer, and the client access directly to the DB using those typed DataSet objects.
I want to change my application to client-server model (which will use web-services for communication).
My question is:
How can I pass typed DataSet objects in the web-services?
For example,
I have a table of persons.
And I want my client side to be able to get specific person (using web-service), update its age, and save the change (again using web service).
Is it possible?
Thanks
Since you are using .Net, you should at least check out Entity Framework (the .Net ORM) prior to going with the 3rd party nHibernate. nHibernate might be fine, and might be the way to go, but you should at least compare it to Entity Framework first and have a reason for not using Entity Framework.
You should try something out like Hibernate. Which is an intermediate entity-based mapping between classes and database tables. The queries would be performed on the business side of the application (web service in your case) in the HQL language; which is very similar to regular SQL. I've personally used it multiple times with Java and it can be quite useful. Doing a brief internet search I found "NHibernate" which is a .NET specific version for Hibernate.
For my specific Java application, it is set up such that the GUI is not on the web-service, while basically everything else is. Then using a resource manager, created a "link" which pointed at the business side. All transactions were performed on the web-service, while they were being displayed on the client side.
So to answer your question; yes it is entirely possible.
I have been looking at the Microsoft examples and most use Entity Framework. However it seems overkill for when I need to make a quick connection. Gets some data from a report and the return it to my web page. It also seems like it is difficult to compose such things as complex SQL that might require a multi-table join and some input parameters.
So what other options are available?
If you want a quick way to connect to your datasrouce you can look into some micro ORM-frameworks:
https://code.google.com/p/dapper-dot-net/
https://github.com/robconery/massive
http://www.toptensoftware.com/petapoco/
These are all tiny libraries that allow you to write your own SQL but still help you (a bit) with mapping the results to classes.
Here is what we do for our reports app that fetches data using Web Api and SQL.
1. Stored Procedures with EF
Since you mention you need to fetch data that might require a multi-table join, best approach here would be to use Stored Procedures to get that data. Import that Stored Procedure to the EntityFramework.
2. Service Layer Class & AutoMapper
Now create a similar object that will map to the Data Layer's object that will be returned from the Stored Procedure you just added. To map these two classes we use a mapper called as AutoMapper. We create two classes because we dont want our web app to directly access the Data Layer classes.
3. Expose your Web API
Now this data can be sent from the api to whoever wants to use it.
Hope this helps.
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.
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.
Hey guys, I hope everyone is doing well.
I have (more-less) a broad question referring to exposing a model to various clients.
Here is my situation: I have a model (sitting on top of Oracle) that is created using EF 4.0 and 3rd party Oracle provider. The model resides in a library so it can be easily referenced by multiple projects.
My goal is to make the model consumable by as many types of clients as possible:
.Net client code (Silverlight, WPF and ASP.Net, services, etc.).
MS Office apps (Excel)
Now, I don’t want to get into the business of creating custom methods over the Model (e.g. GetCustomersWhoAreVeryUpsetOrderedByUpsetRank()). I’d like to be able to expose the model in such way that the client code can decide (at run time) how to construct the queries. Should I take in IQueriable, execute it in a service and return the result data set? Or do I let the client do all the work via the model?
I did give oData a shot but it appears that the client side library used to write Linq queries against the model is rather limiting. In addition the protocol does not support updates.
So my question is what is the best approach/technology/implementation in exposing the Model based on the above mentioned criteria?
Many thanks in advance.
I'd advice you not to share your model 1:1 with your clients or reuse it 1:1 for different clients.
To share with stakeholders, use some simple DTOs. The mapping code can be created automatically with a CASE tool, T4 transformation or any other source code creation. If you share your own model, you run into problems as soon as you have to / want to refactor something or if one client has some specific requirements.
Almost same depends on the query methods from EF (the DAL). Define some DataMappers interfaces with common requirements and implement a default behavior. If you ever need your GetCustomersWhoAreVeryUpsetOrderedByUpsetRank(), you are sill fine since you can add this query to a data mapper deriving from the default mapper. With this approach the core system stays clear and reusable and each client is able to get her/his custom features.