Linq to SQL with WCF in a Multi Tiered Action – Part 1
May 26, 2008 Windows Communication Foundation (WCF), SQL, C# 3.0, .NET 3.5, LINQ 2 CommentsIn many places, forums, blogs, or techy talks with some colleagues I hear some ongoing urban legends about Linq to SQL I came across:
-
You can not implement multi tiered applications with Linq to SQL
-
Linq to SQL can not be used for enterprise level applications
I can’t say that both of these statements are particularly wrong or right, of course Linq to SQL can not handle every scenario but in fairness it handles most of the scenarios sometimes even better than some other RAD oriented ORM s. In this post I will create a simulation of an enterprise web application, having its Data Access, Services, and Presentation Layers separated and let them communicate with each other (err.., at least from service to UI) through WCF – Windows Communication Foundation.
This will be a couple of (may be more) posts, and this is the first part of it. I’ll post the sample code with the next post.
I have to say that this article is neither an introduction to Linq to SQL nor to WCF, so you need basic knowledge of both worlds in order to benefit from this mash up. We will develop an application step by step with an easy scenario but will have the most important characteristics of a disconnected (from DataContext perspective), multi layered enterprise architecture.
Since this architecture is more scalable and reliable, implementing it with Linq to SQL has also some tricks to keep in mind:
-
Our DataContext will be dead most of the time. So we won’t be able to benefit Object Tracking to generate our SQL statements out of the box.
-
This also brings to the table that we have to know what entities to delete, what to insert, and what to update. We can not just “do it” and submit changes as we are doing it in connected mode. This means that we have to maintain the state of the objects manually (sorry folks, I feel the same pain).
-
The transport of the data over the wire is another problem, since we don’t write the entities on our own(and in the case of an amend to them the designer of Linq to SQL can be very aggressive) so it brings us into 2 common situation
-
We can create our own entities, and write translators to convert from Linq Entities to our very own ones.
-
We can try to customize Linq Entities in the ways we are able to.
Since the first one is obvious and the straight forward to implement, we will go down the second route to explore the boundaries of this customization.
To make it clearer that what I will do, here is a basic but a functional schema of the resulting n-tier application
Picture 1 – Architectural schema of the sample app.
In our example, we are going to use Linq to SQL as an ORM Mapper. So as you see in the schema, Linq to SQL doesn’t give us the heaven of not writing a DAL Layer at all. But it reduces both stored queries/procedures and amount of mapping that we had to do manually before.
Developing the Application
Scenario
The scenario I came up with is a favorites web site, that consist of 2 simple pages enabling its users to Insert, Delete, Update and Retrieve users and their favorites when requested. 1 user can have many favorites.
We will simply place 2 Grid Views in the page and handle their events to make the necessary modifications on the model itself. This will also demonstrate a common usage.
Design
Entities
Here is the object diagram of the entities; they are the same as the DB tables:
Picture 2.Entity Diagram
See the additional “Version” fields in the entities; they are type of Binary in .NET and TimeStamps in SQL Server 2005. We will use them to let Linq to SQL handle the concurrency issues for us.
Since we are going to employ a web service by the help of WCF, we need to mark our entities as DataContract to make it available for serialization through DataContractSerializer. We can do that by right clicking on the designer and going to properties, and changing Serialization property to unidirectional as in the picture follows:
Picture 3. Properties window
After doing and saving this we will see in the designer.cs file, we have our Entities marked as DataContract and members as DataMember s.
As mentioned earlier before, we need to maintain our entites state – to know whether they are deleted, inserted, or updated. To do this I am going to define an enumeration as follows:
1: /// <summary>
2: /// The enum helps to identify what is the latest state of the entity.
3: /// </summary>
4: public enum EntityStatus
5: {
6: /// <summary>
7: /// The entity mode is not set.
8: /// </summary>
9: None = 0,
10: /// <summary>
11: /// The entity is brand new.
12: /// </summary>
13: New = 1,
14: /// <summary>
15: /// Entity is updated.
16: /// </summary>
17: Updated = 2,
18: /// <summary>
19: /// Entity is deleted.
20: /// </summary>
21: Deleted = 3,
22: }
We are going to have this field in every entity, so let’s define a Base Entity with this field in it:
1: [DataContract]
2: public class BaseEntity
3: {
4: /// <summary>
5: /// Gets or sets the status of the entity.
6: /// </summary>
7: /// <value>The status.</value>
8:
9: [DataMember]
10: public EntityStatus Status { get; set; }
11: }
And then, all we need to do is to create partial classes for our Entities and extend them from base entity:
1: public partial class User : BaseEntity
2: {
3:
4: }
5:
6: public partial class Favorite : BaseEntity
7: {
8:
9: }
10:
Now our entities are ready to travel safely along with their arsenal.
Service Layer Design
As we are going to use WCF, we need to have our:
- Service Contracts (Interfaces)
- Service Implementations (Concrete classes)
- Service Clients (Consumers)
- Service Host (Web service in our case)
Service Contracts
We will have 2 services: Favorites Service and Users Service. It will have 4 methods: 2 Gets and 2 Updates. We will do the insertion, update, and deletion depending on the status so there is no need to determine separate functions for all. Here is the contract for User:
1: /// <summary>
2: /// Contract for user operations
3: /// </summary>
4:
5: [ServiceContract]
6: public interface IUsersService
7: {
8: /// <summary>
9: /// Gets all users.
10: /// </summary>
11: /// <returns></returns>
12:
13: [OperationContract]
14: IList<User> GetAllUsers();
15:
16: /// <summary>
17: /// Updates the user.
18: /// </summary>
19: /// <param name=”user”>The user.</param>
20:
21: [OperationContract]
22: void UpdateUser(User user);
23:
24: /// <summary>
25: /// Gets the user by id.
26: /// </summary>
27: /// <param name=”id”>The id.</param>
28: /// <returns></returns>
29:
30: [OperationContract]
31: User GetUserById(int id);
32:
33: /// <summary>
34: /// Updates the users in the list according to their state.
35: /// </summary>
36: /// <param name=”updateList”>The update list.</param>
37:
38: [OperationContract]
39: void UpdateUsers(IList<User> updateList);
40: }
And here is the contract for Favorites Service:
1: /// <summary>
2: /// Contract for favorites service
3: /// </summary>
4: [ServiceContract]
5: public interface IFavoritesService
6: {
7: /// <summary>
8: /// Gets the favorites for user.
9: /// </summary>
10: /// <param name=”user”>The user.</param>
11: /// <returns></returns>
12: [OperationContract]
13: IList<Favorite> GetFavoritesForUser(User user);
14:
15: /// <summary>
16: /// Updates the favorites for user.
17: /// </summary>
18: /// <param name=”user”>The user.</param>
19: [OperationContract]
20: void UpdateFavoritesForUser(User user);
21: }
Service Implementations (Concrete classes)
Since we are developing a db application with no business logic at all, the service layer implementors are pretty lean & mean. Here is the Service implementation for UserService
1: [ServiceBehavior(IncludeExceptionDetailInFaults=true)]
2: public class UsersService : IUsersService
3: {
4: IUsersDataAccess DataAccess { get; set; }
5:
6: public UsersService()
7: {
8: DataAccess = new UsersDataAccess();
9:
10: }
11:
12: #region IUsersService Members
13:
14: /// <summary>
15: /// Gets all users.
16: /// </summary>
17: /// <returns></returns>
18: [OperationBehavior]
19: public IList<User> GetAllUsers()
20: {
21: return DataAccess.GetAllUsers();
22: }
23:
24: /// <summary>
25: /// Updates the user.
26: /// </summary>
27: /// <param name=”user”>The user.</param>
28: [OperationBehavior]
29: public void UpdateUser(User user)
30: {
31: DataAccess.UpdateUser(user);
32: }
33:
34: /// <summary>
35: /// Gets the user by id.
36: /// </summary>
37: /// <param name=”id”>The id.</param>
38: /// <returns></returns>
39: [OperationBehavior]
40: public User GetUserById(int id)
41: {
42: return DataAccess.GetUserById(id);
43: }
44:
45: /// <summary>
46: /// Updates the users in the list according to their state.
47: /// </summary>
48: /// <param name=”updateList”>The update list.</param>
49: [OperationBehavior]
50: public void UpdateUsers(IList<User> updateList)
51: {
52: DataAccess.UpdateUsers(updateList);
53: }
54:
55: #endregion
56: }
And as you can imagine the favorite service implementation is pretty much the same.
This has been long enough, so let’s cut it here. In the next post, I will talk about the presentation, service and data layer implementations. By that, we will see how to best approach to modifying these entities in a data grid, pass them through the WCF Proxy and commit the changes (insert, update, delete) to the SQL 2005 database. I will also provide the source codes with the next post. Stay tuned until then.
For part 2 : http://www.sidarok.com/web/blog/content/2008/06/02/linq-to-sql-with-wcf-in-a-multi-tiered-action-part-2.html .
