Right approach in layers/tiers

[Steve Y.]

Hi, I need some input to help my thinking process. We have a multi layer
web application now but we didn't do a very good job separating the business
logic from the user interface logic. So as you can imagine as it is getting
bigger it is harder to maintain. We would really like to pull the business
logic into class objects but I am stuck on the concept. Today the web front
end reacts to events and makes web service calls. The web serivces use the
SQL Helper class (we're still on 1.1) to talk to SQL Server stored procs.
In the web service is the web.config with the server connection string.

We'd like to pull the business logic into separate dlls and reference them
from the front end. So if the front end then knows nothing about the web
services and instead talks to the business objects, how do the business
objects know about the location of the web services? Do we make the web
refrences in the business object class project(s) and have a config file
there? Does the dll and config file then go in the bin directory of the web
front end?

Lastly (sorry for so long of a post), we're thinking about AJAX. My
knowledge is limited, but doesn't ajax have to talk to web services? If so,
how do I use my business logic classes since the business logic classes will
hide the existance that the BO is talking to web services at all.

My hope is that these BOs will become the layer that the web site talks to,
and we can have some other front-ends down the road, not just web sites.

Steven

 

[Michael Lang]

Well...

I'd say you're heading in the direction, but I'd really suggest getting an
experienced architect who has done this before. The key to employing
methodologies and business object frameworks in projects successfully is
unfortunately experience. It takes experience to use methodologies
successfully, it takes experience to create good designs for applications.

If this is not an option for you then I think you'll need to work through
the midnight hour more than a few times to get yourself up to speed.

You are going to find a huge world of different opinions on this subject and
half of those people giving their opinions will be telling you everyone else
with an opinion differing to their own has got it wrong.

My first piece of advice is - don't go overboard on architecture that isn't
immediately required!

The best kind of design is one which fulfills your immediate business
requirements in the most simplistic way possible, but is elegant enough to
be easily extended for future business requirements, without refactoring
your architecture. Nearly always this can be achieved without implementing
a lot of functionality that isn't necessary for your immediate requirements.
Going down that track is a big mistake.

If your immediate business requirements are quite complex I'd really
recommend that you do some sort of design...

I'd recommend using UML. I have a page here that takes you through the
basics of UML class diagrams and interaction diagrams...

http://www.mblmsoftware.com/umlbasics.aspx

....which can get you started if you've never seen UML before. Someone who
knows what they're doing in UML can design a system pretty quickly within a
day or two that can give you a good road map for a system that might take
weeks or months of coding, having a good road map can save you lots of time.

Most projects that fail or go over schedule are often ones that have
repeated refactoring of the application's architecture. This is exactly
what you're doing now from the sounds of it, that means you definitely want
to make sure you get it right this time, otherwise you'd probably be better
off persisting on with development in it's present state.

There are many frameworks out there that can help you create business
objects that do a lot of the work required to bind objects to win/web forms
and persist them to the database. I have developed my own business objects
library and framework, which I might one day release, but I'm aware of
several other solutions already publicly available for .NET such as...

http://www.hibernate.org/

This guy has a book and a class library on business objects called CSLA.NET.

http://www.lhotka.net/

There are going to be many more out there.

Again I've not actually used these myself as I've got my own business
objects framework which has many of the features offered by these two
frameworks. Anyone out there who has used one of these who would like to
comment please do, I'd be quite interested in what you have to say about
them.

You want to be careful that you choose something that is right for your
architecture. It is possible a business object framework might be more
suited to a windows development environment which is inherently more
stateful than ASP.NET. If you're going to be using this for ASP.NET you want
to be careful that the tear down and startup times are not too great.

You also want to think about scalability, if your system is going to
encounter considerable load you might want to considering technologies that
may be used to farm your business objects across several machines such as
MTS, remoting or some of vista's new technologies. But again don't go
overboard, implement the system you need now, not the one two releases away.

I could keep writing here but you could write a whole book on your email (as
lhotka has done).

Best of luck...

Michael
www.mblmsoftware.com

 

[sloan]

Check out
http://sholliday.spaces.live.com/
5/24/2006
Custom Objects/Collections and Tiered Development

At the bottom of the article, I reference a msdn article ("read from start
to finish").




You should also look at .Net Remoting.

See
9/27/2005
Leveraging Dot Net Remoting To Keep Your "Secret Code" Safe

 

[Flinky Wisty Pomm]

Lastly (sorry for so long of a post), we're thinking about AJAX. My

knowledge is limited, but doesn't ajax have to talk to web services? If so,
how do I use my business logic classes since the business logic classes will
hide the existance that the BO is talking to web services at all.

Firstly, +1 for the poster who said don't architect for the hell of it,
but if you want to stick another UI/winforms/console app on top of your
existing ASP.Net application, read on.


Ajax doesn't need to talk to web services, no. If you want to use AJAX,
I'd use something like Atlas Professional.Net and expose the methods of
the Presenter class as AjaxMethods , then write a View that uses Ajax
to communicate with the Presenter, but I'm getting ahead of myself.


Here's what I would do:

1) Find a fairly simple page in your app as a test bed
2) Create a new class to contain the business logic for your page, this
is a Presenter.
3) Go through the page class and look for methods and data. If data is
directly displayed on screen, leave it in the page, if data is used for
state or calculations behind the scenes, move it to the Presenter.

Likewise, move the logic from your page events into the bl class. So
your event handlers end up looking like:

protected void SomeEventHappend(object sender, EventArgs e)
{
if(Page.IsValid)
BusinessLogicClass.DoAssociatedActions();
}

4) you should end up with a very thin page class (the View) that
contains methods and data only for displaying stuff to the end user and
accepting user input. The flow of the page, and the marshalling of data
should be hidden away in your business logic class.

The actual data access remains in your web services.

5) Extract an interface from your page class. For example, the
interface for a log in page might look like

public interface ILoginView
{
string Password{ get; }
string Username { get; }
void OnLoginComplete(bool successful);
}

The pattern you're refactoring to is Model-View-Presenter which is
getting much love in the ASP.Net community at the moment.

[http://codebetter.com/blogs/jeremy.miller/archive/2006/02/01/137457.aspx]
[http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/]
[http://www.codeproject.com/useritems/ModelViewPresenter.asp]

 

[Michael Lang]

One other comment I might make here, is that I cringe a bit when I hear
people talking about calling web services from asp.net web sites....

My approach in the past has been to create a set of business objects that
talk to your via a datalayer to your datasource (in this case sql server)
and then expose that business layer to both the ASP.NET web application and
the ASP.NET web service. Where the web service is an alternate interface
for other systems to use instead of your web application.

I suppose one reason why you might choose web services is the ability to
create a web farm of the web services to enable scalability on your middle
tier. However, you can achieve the same end farming your business objects
through mts or remoting.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenethowto07.asp

That link might help.

My reasons for this choice are SOAP and web services are not performant.
There is a very high cost for using them, that cost must offset by a gain
such as cross platform interoperability, and by this I mean you have several
systems on different platforms using the service. Perhaps it could be
justified when you want RPC across a WAN, and the time for serialization
becomes a smaller percentage of the overall time for a transaction. But
this is definitely not the case when both the Web Service and the Web App
are sitting on the same LAN.

But this is just my choice and the reasons behind it. If you really want to
structure things this way then perhaps you could create a set of interfaces
for your business objects and then implement a set of business objects that
realise those interfaces that talk to sql server and another set that talk
to your web service. If you take this approach make sure that both your
ASP.NET web service and application talk ONLY via interfaces.

I've seen so many examples (even off MSDN) where ppl have created interfaces
only to then cast to the implementing class to do the "real work". When I
see this, I feel like getting a gun, tracking these ppl down, and putting
them out of their misery.

And yes... you definitely should have the details for your webservice in a
config file. The settings for your web service are obviously going to
change between development, testing, and deployment, this is a little
difficult to do if you service settings are not in the config file.

In the past I have treated web services as a datalayer... usually I wrap a
web service within a class that implements a datalayer interface and then
have a business object layer talk via that datalayer. Be aware that a web
service is an interface external to your application and is likely to
change, you want to make sure your system is robust to changes in the web
service interface. This is usually done by averting the use of web service
structures any where other than in the data layer. Use XSL or some other
transform to copy the data into a structure local to your application.

www.mblmsoftware.com
Michael