Design help.

[John Sitka]

Hi, sorry for a crosspost but that other news group was showing last post was a
week ago so I guess it dosen't see much use...

I'm about to start a solution and I'm curious about the approach of a webservices project.
Should the objects be represented in classes such as...

public class Orders (ie Orders.cs) within a project
and then have the service be in a class like OrdersService.asmx
public class OrdersService : System.Web.Services.WebService
and this class contain only [WebMethod] 's

I guess another another way to ask the same question is..
Would it be less desireable if a class inheriting System.Web.Services.WebService
contain methods that are not [Web Method]

[Claus Konrad [MCSD]]

You are on the correct path!
The better design approach is to declare your interfaces first.

1) Declare interfaces
2) Implement this interface in your classes (C# class).
3) Implemtent the webservices classes from the same interface
4) In the WS, authenticate and authorize access to the business logic
implemented in your "true" classes (step 2).

Why?
Well - first of all it forces you to take a contract-first approach. Next it
allows you to call the logic from another "client" than the webservice that
exposes the methods. Second it de-couples the businss from the fact that it
is exposed as a webservices; not really a businnss entiity, is it?

Example:

public interfaces IOrder
{
string GetSomething(arguments...);
}

public class Order : IOrder
{
//..
}

[WebService]
public class OrderService : WebService, IOrder
{

[WebMethod]
public string GetSomething((arguments..)
{
//authorize
//if not allowed access - throw UnAuthorizedAccessException!

//instantiate businnss logic

//return data
}

}

--
rgds.
/Claus Konrad
MCSD.NET (C#)
"John Sitka" wrote:

Hi, sorry for a crosspost but that other news group was showing last post was a
week ago so I guess it dosen't see much use...

I'm about to start a solution and I'm curious about the approach of a webservices project.
Should the objects be represented in classes such as...

public class Orders (ie Orders.cs) within a project
and then have the service be in a class like OrdersService.asmx
public class OrdersService : System.Web.Services.WebService
and this class contain only [WebMethod] 's

I guess another another way to ask the same question is..
Would it be less desireable if a class inheriting System.Web.Services.WebService
contain methods that are not [Web Method]

[John Sitka]

Thank you, I'm not skilled enough to understand though.

"Claus Konrad [MCSD]" <Cl*************@discussions.microsoft.comwrote in message
news:0E**********************************@microsof t.com...

You are on the correct path!
The better design approach is to declare your interfaces first.

1) Declare interfaces
2) Implement this interface in your classes (C# class).
3) Implemtent the webservices classes from the same interface
4) In the WS, authenticate and authorize access to the business logic
implemented in your "true" classes (step 2).

Why?
Well - first of all it forces you to take a contract-first approach. Next it
allows you to call the logic from another "client" than the webservice that
exposes the methods. Second it de-couples the businss from the fact that it
is exposed as a webservices; not really a businnss entiity, is it?

Example:

public interfaces IOrder
{
string GetSomething(arguments...);
}

public class Order : IOrder
{
//..
}

[WebService]
public class OrderService : WebService, IOrder
{

[WebMethod]
public string GetSomething((arguments..)
{
//authorize
//if not allowed access - throw UnAuthorizedAccessException!

//instantiate businnss logic

//return data
}

}

--
rgds.
/Claus Konrad
MCSD.NET (C#)
"John Sitka" wrote:

>Hi, sorry for a crosspost but that other news group was showing last post was a
week ago so I guess it dosen't see much use...

I'm about to start a solution and I'm curious about the approach of a webservices project.
Should the objects be represented in classes such as...

public class Orders (ie Orders.cs) within a project
and then have the service be in a class like OrdersService.asmx
public class OrdersService : System.Web.Services.WebService
and this class contain only [WebMethod] 's

I guess another another way to ask the same question is..
Would it be less desireable if a class inheriting System.Web.Services.WebService
contain methods that are not [Web Method]

[Claus Konrad [MCSD]]

Fair enough.

In that case: It is best practice NOT to implement business logic directly
in the WebService methods. Do this in dedicated dll's (assemblies).

Let the webservice methods expose this logic to the "world", no more.
It is the job of the webservice to decide whether clients are allowed to use
the logic though, hence let the webservice authorize access or not to the
business logic.

If allowed access - instantiate the business logic and delegate the call to
these components.

Is this more clear?
--
rgds.
/Claus Konrad
MCSD.NET (C#)
"John Sitka" wrote:

Thank you, I'm not skilled enough to understand though.

"Claus Konrad [MCSD]" <Cl*************@discussions.microsoft.comwrote in message
news:0E**********************************@microsof t.com...

You are on the correct path!
The better design approach is to declare your interfaces first.

1) Declare interfaces
2) Implement this interface in your classes (C# class).
3) Implemtent the webservices classes from the same interface
4) In the WS, authenticate and authorize access to the business logic
implemented in your "true" classes (step 2).

Why?
Well - first of all it forces you to take a contract-first approach. Next it
allows you to call the logic from another "client" than the webservice that
exposes the methods. Second it de-couples the businss from the fact that it
is exposed as a webservices; not really a businnss entiity, is it?

Example:

public interfaces IOrder
{
string GetSomething(arguments...);
}

public class Order : IOrder
{
//..
}

[WebService]
public class OrderService : WebService, IOrder
{

[WebMethod]
public string GetSomething((arguments..)
{
//authorize
//if not allowed access - throw UnAuthorizedAccessException!

//instantiate businnss logic

//return data
}

}

--
rgds.
/Claus Konrad
MCSD.NET (C#)
"John Sitka" wrote:

Hi, sorry for a crosspost but that other news group was showing last post was a
week ago so I guess it dosen't see much use...

I'm about to start a solution and I'm curious about the approach of a webservices project.
Should the objects be represented in classes such as...

public class Orders (ie Orders.cs) within a project
and then have the service be in a class like OrdersService.asmx
public class OrdersService : System.Web.Services.WebService
and this class contain only [WebMethod] 's

I guess another another way to ask the same question is..
Would it be less desireable if a class inheriting System.Web.Services.WebService
contain methods that are not [Web Method]

[John Sitka]

Yes, I think I kind of froze up when you mentioned contract first, I started having visions
of having to maintain the WSDL in notepad. The more I tried to understand the more I realized
I'm not at that level yet. Really the original question was derived after looking at some sample code,
I thought to myself, Since all the webservice is doing is relfecting the methods why would
I put any business logic in the .asmx code. At least that instinct, while probably not absolutely
true in all cases, was kind of correct.
Thanks

"Claus Konrad [MCSD]" <Cl*************@discussions.microsoft.comwrote in message
news:88**********************************@microsof t.com...

Fair enough.

In that case: It is best practice NOT to implement business logic directly
in the WebService methods. Do this in dedicated dll's (assemblies).

Let the webservice methods expose this logic to the "world", no more.
It is the job of the webservice to decide whether clients are allowed to use
the logic though, hence let the webservice authorize access or not to the
business logic.

If allowed access - instantiate the business logic and delegate the call to
these components.

Is this more clear?
--
rgds.
/Claus Konrad
MCSD.NET (C#)
"John Sitka" wrote:

>Thank you, I'm not skilled enough to understand though.

"Claus Konrad [MCSD]" <Cl*************@discussions.microsoft.comwrote in message
news:0E**********************************@microso ft.com...

You are on the correct path!
The better design approach is to declare your interfaces first.

1) Declare interfaces
2) Implement this interface in your classes (C# class).
3) Implemtent the webservices classes from the same interface
4) In the WS, authenticate and authorize access to the business logic
implemented in your "true" classes (step 2).

Why?
Well - first of all it forces you to take a contract-first approach. Next it
allows you to call the logic from another "client" than the webservice that
exposes the methods. Second it de-couples the businss from the fact that it
is exposed as a webservices; not really a businnss entiity, is it?

Example:

public interfaces IOrder
{
string GetSomething(arguments...);
}

public class Order : IOrder
{
//..
}

[WebService]
public class OrderService : WebService, IOrder
{

[WebMethod]
public string GetSomething((arguments..)
{
//authorize
//if not allowed access - throw UnAuthorizedAccessException!

//instantiate businnss logic

//return data
}

}

--
rgds.
/Claus Konrad
MCSD.NET (C#)
"John Sitka" wrote:

Hi, sorry for a crosspost but that other news group was showing last post was a
week ago so I guess it dosen't see much use...

I'm about to start a solution and I'm curious about the approach of a webservices project.
Should the objects be represented in classes such as...

public class Orders (ie Orders.cs) within a project
and then have the service be in a class like OrdersService.asmx
public class OrdersService : System.Web.Services.WebService
and this class contain only [WebMethod] 's

I guess another another way to ask the same question is..
Would it be less desireable if a class inheriting System.Web.Services.WebService
contain methods that are not [Web Method]