I'm converting the business layer of a web app (ASP.Net) to a web service.
The business layer is simply a class library of custom types and controller
classes that act on those types. Some of the custom types have validation
code in property setters, for example:

Serializable()> _
Public Class PhoneNumber

Private _TheNumber as UInt64

Public Property TheNumber as UInt64
Get
Return _TheNumber
End Get

Set (ByVal Value As UInt64)
If Value = 0 Then
Throw New ArgumentException("Invalid phone number")
End If
_TheNumber = Value
End Set
End Property

End Class

Obviously, a client app that consumes the web service can assign a value of
zero (0) to "TheNumber", because executable code is not serialized.

Architecturally how should this be handled? I have quite a few classes
(custom types) like the example above.

milop wrote:
I'm converting the business layer of a web app (ASP.Net) to a web
service. The business layer is simply a class library of custom types and
controller classes that act on those types. Some of the custom types have
validation code in property setters, for example:

Serializable()> _
Public Class PhoneNumber

Private _TheNumber as UInt64

Public Property TheNumber as UInt64
Get
Return _TheNumber
End Get

Set (ByVal Value As UInt64)
If Value = 0 Then
Throw New ArgumentException("Invalid phone number")
End If
_TheNumber = Value
End Set
End Property

End Class

Obviously, a client app that consumes the web service can assign a value
of zero (0) to "TheNumber", because executable code is not serialized.

The UI/client app should never consume the Web service directly.


Architecturally how should this be handled? I have quite a few classes
(custom types) like the example above.


A Web service is not a Business Layer. A Web service can pass an object to
the Business layer that sits behind the Web service when the object is
passed to it.

The Business layer validates the object based on the object's business
rules using a Broken Rules pattern.

If the object is not valid due to rules for the object have been broken,
then the object is marked invalid, the object holds its broken rule
message or messages and the object is sent back via the Web service so
that the message or messages can be displayed if the object is being sent
back to a UI layer or other layer, otherwise, the object is valid.

If the object is valid, then it can be sent to the DAL to be persisted to
the database, which is also sitting behind the Web Service.


Have you used or know about design patterns, which there are ones for SOA?

Thanks for responding, Mr. Arnold.

I oversimplified the example. The web service is just a channel, I
understand this. It has no business rules in it nor does it communicate
with the data layer.

My business layer resides in separate assemblies (projects). My data
access layer also resides in separate assmblies. Please keep in mind I'm
rewriting an ASP.Net web app that has access to the BL. Processing is
performed on the server so object serialization and such (other than
persisting session state to a database) was not an issue. Creating a new
user type and throwing exceptions when the rules were violated is handled.

So, back to "converting" this app to web services. After a little
brainstorming I figure the web service project should reference those
assemblies and the client app should also reference those assemblies.
Thus, both apps have copies of the same BL. That's appropriate in my
opinion especially if you want to catch errors at the client when user
types are instantiated and properties are set (for example); basic object
integrity stuff. I don't want to go over the wire just to see if a
PhoneNumber object is valid.

My concern is when something in the BL changes. All apps that reference
the BL would need, at the very least, a rebuild. To coordinate this in
Visual Studio I figure I could add all projects into one solution and
rebuild the solution. Thus all apps that reference the BL would get the
same copy of the new assemblies,

Does any of this make sense?

So, actually, not only did my original post concern architectural design,
but also a coordination issue inside of Visual Studio.

Also, I'm not quite sure by what you meant when you wrote "The UI/client
app should never consume the Web service directly". If I have a Windows
Forms app and need to call one of the webservice's functions, without
adding a Web Reference, how is it done?

Yes, I have read a bit on SOA, in a cursory manner, but this is the first
"real" app that I'm doing. I've done plenty of smaller ones where it's
just a slam dunk. This project is a big one.

I'm very familiar with Microsoft's Patterns and Practices, I visit the
site often, and even have some books. I will take a in depth review for
sure, but in the mean time can you offer just a little more assistance
regarding my thoughts, above? I'm a fast learner.

snipped

Oh, one other thing, legacy ASP.NET Web services are dead as MS is
leveraging it out in favor of WCF ASP.NET Web services.


__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4516 (20091016) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

"milop" <milop at (no spam) slomins.com> wrote in message
news:eMWS%23brTKHA.5052 at (no spam) TK2MSFTNGP06.phx.gbl...
Thanks for responding, Mr. Arnold.

I oversimplified the example. The web service is just a channel, I
understand this. It has no business rules in it nor does it communicate
with the data layer.

My business layer resides in separate assemblies (projects). My data
access layer also resides in separate assmblies. Please keep in mind I'm
rewriting an ASP.Net web app that has access to the BL. Processing is
performed on the server so object serialization and such (other than
persisting session state to a database) was not an issue. Creating a new
user type and throwing exceptions when the rules were violated is
handled.

Some like to do it that way, but I have never found that to be a best
practice.


So, back to "converting" this app to web services. After a little
brainstorming I figure the web service project should reference those
assemblies and the client app should also reference those assemblies.
Thus, both apps have copies of the same BL. That's appropriate in my
opinion especially if you want to catch errors at the client when user
types are instantiated and properties are set (for example); basic object
integrity stuff. I don't want to go over the wire just to see if a
PhoneNumber object is valid.

No, a DTO (Data Transfer Object) and a Presentation Layer of a MVP should
sit between the UI and the BLL or Web Servcice, with the DTO on an
Interface used between the UI and MVP. The UI should really be unware of
the BLL or Web Service.

Now, some like to have the Presenter layer in contact with the BLL so it
can be sent back to the UI, since most consider the Presentation layer as
part of the UI setting infront of the Web Service.


My concern is when something in the BL changes. All apps that reference
the BL would need, at the very least, a rebuild. To coordinate this in
Visual Studio I figure I could add all projects into one solution and
rebuild the solution. Thus all apps that reference the BL would get the
same copy of the new assemblies,

Does any of this make sense?

Yeah, but is it a best practice.


So, actually, not only did my original post concern architectural design,
but also a coordination issue inside of Visual Studio.

Also, I'm not quite sure by what you meant when you wrote "The UI/client
app should never consume the Web service directly". If I have a Windows
Forms app and need to call one of the webservice's functions, without
adding a Web Reference, how is it done?

See below and consider MVP.


Yes, I have read a bit on SOA, in a cursory manner, but this is the first
"real" app that I'm doing. I've done plenty of smaller ones where it's
just a slam dunk. This project is a big one.

I'm very familiar with Microsoft's Patterns and Practices, I visit the
site often, and even have some books. I will take a in depth review for
sure, but in the mean time can you offer just a little more assistance
regarding my thoughts, above? I'm a fast learner.


I'll give it to you, and when you're done, you'll know what to do and what
it's all about.

You say you're a fast learner, huh? <smile


What is Object-oriented-programming?

(OOP) is a programming paradigm that uses "objects" and their interactions
to design applications and computer programs.

The key concepts of OOP are the following:

Class

Object

Instance

Method

Message passing

Inheritance

Abstraction

Encapsulation

Polymorphism

Decoupling



http://en.wikipedia.org/wiki/Object-oriented_programming

No matter what development platform Java, .Net or others OOP is OOP.

http://math.hws.edu/eck/cs124/downloads/OOP2_from_Univ_KwaZulu-Natal.pdf

http://www.blackwasp.co.uk/ObjectOrientedConcepts.aspx



What are design patterns?

Design patterns are recurring solutions to software design problems you
find again and again in real-world application development. Patterns are
about design and interaction of objects, as well as providing a
communication platform concerning elegant, reusable solutions to commonly
encountered programming challenges.

http://www.developer.com/design/article.php/1502691

http://www.dofactory.com/Patterns/Patterns.aspx

http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns

http://msdn.microsoft.com/en-us/library/ms954638.aspx

http://www.designpatternsfor.net/Presentations.aspx?tid=3&cid=4



Now, milop get the book and get the DOAFactory software and learn.

http://headfirstlabs.com/books/hfdp/



Head First is in the dofactory.

http://www.dofactory.com/Framework/Framework.aspx



What is Domain Driven Design?

(DDD) is an approach to the design of software, based on the two premises
[1] that complex domain designs should be based on a model, and that, for
most software projects, the primary focus should be on the domain and
domain logic (as opposed to being the particular technology used to
implement the system).

http://en.wikipedia.org/wiki/Domain-driven_design



What is Test Driven Design?

(TDD) is a software development technique that uses short development
iterations based on pre-written test cases that define desired
improvements or new functions. Each iteration produces code necessary to
pass that iteration's tests. Finally, the programmer or team refactors the
code to accommodate changes. A key TDD concept is that preparing tests
before coding facilitates rapid feedback changes. Note that test-driven
development is a software design method, not merely a method of testing.

http://en.wikipedia.org/wiki/Test-driven_development

http://weblogs.asp.net/rhurlbut/archive/2007/07/16/another-tdd-and-ddd-success-story.aspx



What is Model -View- Controller?

(MVC) is an architectural pattern used in software engineering. Successful
use of the pattern isolates business logic from user interface
considerations, resulting in an application where it is easier to modify
either the visual appearance of the application or the underlying business
rules without affecting the other. In MVC, the model represents the
information (the data) of the application; the view corresponds to
elements of the user interface such as text, checkbox items, and so forth;
and the controller manages the communication of data and the business
rules used to manipulate the data to and from the model.

http://en.wikipedia.org/wiki/Model-view-controller

http://msdn.microsoft.com/en-us/library/ms978748.aspx

http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx

http://cristobal.baray.com/indiana/projects/mvc.html

http://www.devx.com/dotnet/Article/29992/0/page/1



What is Model -View- Presenter?

MVP is a software pattern considered a derivative of the
Model-view-controller.

http://en.wikipedia.org/wiki/Model_View_Presenter

http://msdn.microsoft.com/en-us/magazine/cc188690.aspx

http://mrrask.files.wordpress.com/2008/01/model-view-presenter.pdf

http://www.mvcsharp.org/Reworking_ASPNET_MVC_Store/Default.aspx

http://www.codeproject.com/KB/aspnet/ModelViewPresenter1.aspx?fid=1531640&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2822806#Reusing%20the%20presenter%20in%20windows

http://codebetter.com/blogs/jeremy.miller/archive/2006/02/01/test-driven-development-with-asp-net-and-the-model-view-presenter-pattern.aspx



MODEL-VIEW-PRESENTER

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5



What is Object Relational Mapping?

(ORM) is a programming technique for converting data between incompatible
type systems in relational databases and object-oriented programming
languages. This creates, in effect, a "virtual object database," which can
be used from within the programming language. There are both free and
commercial packages available that perform object-relational mapping,
although some programmers opt to create their own ORM tools.

http://en.wikipedia.org/wiki/O-RM

http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html



What is Language Integrated Query?

LINQ is a Microsoft .NET Framework component that adds native data
querying capabilities to .NET languages.

Microsoft LINQ defines a set of query operators that can be used to query,
project and filter data in arrays, enumerable classes, XML, relational
database, and third party data sources. While it allows any data source to
be queried, it requires that the data be encapsulated as objects. So, if
the data source does not natively store data as objects, the data must be
mapped to the object domain. Queries written using the query operators are
executed either by the LINQ query processing engine or, via an extension
mechanism, handed over to LINQ providers which either implement a separate
query processing engine or translate to a different format to be executed
on a separate data store (such as on a database server as SQL queries).
The results of a query are returned as a collection of in-memory objects
that can be enumerated using a standard iterator function such as C#'s
foreach.

Many of the concepts that LINQ has introduced were originally tested in
Microsoft's C? research project. LINQ was released as a part of .NET
Framework 3.5 on November 19, 2007.

http://en.wikipedia.org/wiki/Language_Integrated_Query



What is Linq-to-SQL?

LINQ to SQL, a component of Visual Studio Code Name "Orcas", provides a
run-time infrastructure for managing relational data as objects without
losing the ability to query. It does this by translating
language-integrated queries into SQL for execution by the database, and
then translating the tabular results back into objects you define. Your
application is then free to manipulate the objects while LINQ to SQL stays
in the background tracking your changes automatically.

http://msdn.microsoft.com/en-us/library/bb425822.aspx



What is ADO.NET Entities framework?

ADO.NET Entity Framework is an object-relational mapping (ORM) framework
for the .NET Framework. This framework is Microsoft's first ORM offering
for the .NET Framework. While Microsoft provided objects to manage the
Object-relational impedance mismatch (such as a DataSet).

ADO.NET Entity Framework is included with .NET Framework 3.5 Service Pack
1 and Visual Studio 2008 Service Pack 1, released on 11 Aug 2008. It also
includes the capability of executing LINQ against ADO.NET Entity Framework
entities

http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework

http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx

http://www.springerlink.com/content/kg3216v2014r00u0/

http://blogs.msdn.com/adonet/archive/2008/03/27/ado-net-entity-framework-performance-comparison.aspx



__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4516 (20091016) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com