.net Web services best practice...SRP?

Question

What is considered the appropriate development for .asmx or wcf service classes regarding how many files, lines of code, responsibilities, etc? Do most people publish separate .asmx service files for the different crud methods for every class?

Answer 1

Grab this book from wherever you can:

Service Oriented Architecture (SOA): Concepts, Technology, and Design

Answers each of your questions and many many more you're bound to run into during your implementation.

Answer 2

First of all, the best practice for new development is to use WCF. See Microsoft: ASMX Web Services are a “Legacy Technology”.

Second, in SOA, one tries to create services with coarsly-grained operations. For instance, you would want an OrderProduct operation, rather than StartOrder, AddLineItem, AddOption, FinishOrder operations. The OrderProduct operation might accept an OrderDTO as follows:

public class OrderDTO {
    public CustomerInfo Customer {get;set;}
    public DateTime OrderTime {get;set}
    public DateTime ShipTime {get;set;}
    public List<LineItemDTO> LineItems {get; private set;}
}

public class LineItemDTO {
    public int LineItemNumber {get;set;}
    public string ProductName {get;set;}
    public int Quantity {get;set}
    public Decimal Amount {get;set}
    public Decimal ExtendedAmount {get;set;}
}

Rather than a StartOrder method that just creates an empty order, followed by AddLineItem calls to add individual line items (as you might do from a desktop application), I'm recommending a single OrderProduct method that accepts an OrderDTO, which will have a collection of LineItemDTO. You'll send the entire order all at once, add all the pieces in a transaction, and be done.

Finally, I'd say that you should still separate into business and data layers. The service layer should be concerned only with the services side of things, and will call on your business logic layer in order to get things done.

Answer 3

Generally speaking, a service should encapsulate a set of common operations. Regardless of whether you use ASMX or WCF, you shouldn't be creating one "service" for each operation. The general idea behind service-oriented architecture (SOA) is to model real-world business behavior. To give you a dumb, but hopefully effective, example...think of a waitress at a restaurant. The waitress provides a service to customers in the form of taking orders, serving those orders, providing drink refills, providing condiments, and finally handling payment. The service the waitress offers is not a single operation, its an aggregation of related operations.

However, it doesn't stop there. The true nature of SOA is that any given service is likely to rely on other services. The waitress can not do her job without relying on the services of the cook, to provide meals, the person serving the counter, where she can get instances of condiments and drink, and the services provided by the restaurant building itself. There are also some fundamental differences between the kind of service provided by a waitress, and that provided by a cook. To bring it down to technical programming terms...a Waitress is a task service, but a Cook is an entity (or CRUD) service. The waitress handles higher level operations that provide useful functionality to clients, while the cook handles lower level operations that provide fine-grained and complex functionality only to other employees of the restaurant.

I can't really give you a specific answer to your question, other than to say just organize your services however they logically fit. Its probably not a good practice to have one operation per service...however, it is not unheard of for a service to have just one operation. Task services often have just one operation. Entity services often have many operations, usually CRUD based, but sometimes additional services. There are also Utility services that provide lowest level, infrastructural operations (back to the restaurant, utility services would be like stoves, grills, the register, etc.) If you model your services after actual business concepts, then the operations they expose and their dependencies on each other should eventually become clear.

For some GREAT information on SOA, check out the SOA series by Thomas Erl (Prentice Hall), as they are the definitive resource for implementing a service-oriented enterprise.