Question

I just got off a small project using a WCF/REST Web Service that used Entity Framework to access a database, apply some minor business logic, and pass the results to .NET Webforms front end. That worked pretty well, but the initial design was thrown together without a lot of time to investigate options, and now I’m being asked to do another very similar project. I have a bit more time now to see what’s out there and potentially do this project better than the first.

I want to find out if there are better ways to accomplish the a few things, specifically around passing objects back and forth between the web service and the front end.

For the first project, I created a shared library with class definitions that both the web service and the Website used. When a request came in to the web service, DB queries were performed, business logic was applied, and an object of one of the shared types was created and passed back in the web service response.

When the website got the response, it deserialized it to the appropriate shared object and went on its merry way.

It worked fine, but there was a lot of code that had to be written to define a shared object, then map the query results/business logic results to the shared object.

Is there a better way? Specifically what I’m looking for would be a way to:

• automatically generate objects. (I’m not sure there is – it seems like I could autogenerate objects that were specifically mapped to database entities like tables or views (and indeed, that’s what the Entity Framework does) but what about objects that need to include non-DB info like stuff the business logic might add?)

• remove the requirement for a shared library between the Web Service and the Website. I suspect this might exist, but I’m not even sure where to start on it.

Answer 1

I am working on a similar project and here is what I am doing (you can decide if it works for you or not).

• View uses a UIModel
• When a function is called, I pass my UIModel to a ServiceManager that maps the UIModel to a ServiceModel
• The ServiceManager sends the ServiceModel to the service (I am using RestSharp to cut down on the mapping code)
• My service receives the ServiceModel and immediately maps it to a BusinessModel (I am using ServiceStack to, again, cut down on the mapping code)
  • The service’s only job is to unwrap the service object and route it appropriately. This hides the internal details of my actual business layer. If that is not important to you, then your BusinessModel can be the same as you ServiceModel (and potentially the same as your database model)
• My service sends the business model to a BusinessManager, which does any business logic and then creates a PersistenceModel to be passed into a RepositoryManager to be persisted
• Then the whole process is reversed

So, I end up with 4 models as summarized below:

• UI has its own model
• ServiceManager and Service share a model (which is also the point of the ServiceManager; to separate the concern of the UI from the service)
• Business logic has its own model
• Persistence logic has its own model

This, as already mentioned above, allows for a separation of concerns. I can potentially change my persistence model without the need to change my contracts set in the service (which will be public). This will make it so that internal changes do not break external applications. You do run the risk of having to change all models, though.

As to the boilerplate of mapping them all together, I am using AutoMapper. So, the code is not cluttered up with mappings due to AutoMapper, RestSharp, and ServiceStack. The code looks like code 🙂

I am not sure if that entirely answers your question, but it does sound kind of like what you are explaining.

UPDATE:

This is to try to take the above and make it even more specific to the BDW’s ASP.NET solution:

• Create a separate project that will only store your UIModels.
• Reference that in your asp.net project, and expect to use that for any asp.net logic
• Create a separate project that will only store your ServiceModels.
• Whenever you need to call the Service, convert the data from your UIModel to your ServiceModel
  • This can be done inside your asp.net project. Or, you can create a new project that will take in the UI model and do the conversion and service call for you (that way your servicemodel does not have to be referenced in the asp.net portion)
• Create another project that will call the service for you, using the ServiceModel
• Now, you are in your service and per your comment, you can handle the rest