If you have a need to write a new service, and would prefer to write this service using the controller methods and entities library...now you can.
As most of you know, the Services portion of the business layer uses NameValuePairs exclusively as a data container, and usually calls other services if it is a "work flow" or "Controller" type service. Instead of keeping the data in this container, and writing your business logic using Name Value Pairs and directly calling other services, you now have the capability to simply use the Controller methods and entities. An example of this can be found at in the ProTrans.Enterprise.Services_CSharp project, and the ShipperManagedCallQueue class.
public class ShipperManagedCallQueue : ControllerServiceBase
{
protected override NameValuePairs.Interface ExecuteRun(NameValuePairs.Interface request)
{
List lst = ControllerClient.ShipperConsigneeGetListByCallSchedule(DateTime.Now);
foreach(ShipperConsignee shipConsignee in lst)
{
// Ignore shippers that aren't responsible for their call schedule
if (!shipConsignee.IsShipperResponsibleForCallSchedule.HasValue ||
!shipConsignee.IsShipperResponsibleForCallSchedule.Value)
***************
A few things to notice here is that this service does not inherit from the usual Services.Base in the frameworks project, it inherits from ControllerServiceBase, which gives you access to the controllers in the same way that you have access to this via the code-behind on web pages.
Why Is This Important?
This is important, because it will improve our code re-use of the common tasks within our batch processing areas. Code re-use is important because having a code-reusability mindset lends itself to higher quality software (by virtue of the fact that you will be writing building blocks for the business code, and you will write tests, and with a foundation like that you are setting yourself up to be more successful over time). Usually you would write a service like this when you are doing some batch process, which brings me to my next question...
When Would I Use This?
You would use this when the service that you are writing, is one that could simply use a collection of Controller methods. For instance, if you are writing a service that iterates over a list of Shipments, and makes adjustments and re-saves them...you would not want to rewrite all of the business logic around saving a shipment, you would simply want to call ControllerShipment.ShipmentSave(...), because all of the business rules have been encapsulated and tested inside of this method. A good candidate for this type of service would be a batch job that needs to be scheduled, or a business process that we have to expose to one of our internal non-.Net applications (like ProTrack). This is where the service architecture shines, because of it's extensible interface (NameValuePair in NameValuePair out), it can be connected to our legacy systems in a common fashion. There are many uses for this, but there are also consequences and possibly dangerous issues that need to be thought about and accounted for before making the decision.
How Could This Be Dangerous?
This is a powerful technique, because it is allowing the NVP-based services to utilize the simplicity and organization of the Controllers and Entities, however, as those of you who have written Controller methods know...they use the NVP services to do their work. So if you think about this, Controllers are using services, and now we are allowing services to use Controllers, could be dangerous right? Yes and no...yes academically you could run into a situation where you write a service that is calling a controller method that in turn is calling that same service (this is referred to as a circular reference). However, the likelihood of this happening is remote, because of the style of services you are using in the Controller methods are vastly different from the style of services you would implement this technique.
