Right approach in layers/tiers

Discussion in 'ASP .Net' started by Steve Y., Nov 5, 2006.

  1. Steve Y.

    Steve Y. Guest

    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
     
    Steve Y., Nov 5, 2006
    #1
    1. Advertisements

  2. Steve Y.

    Michael Lang Guest

    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
     
    Michael Lang, Nov 5, 2006
    #2
    1. Advertisements

  3. Steve Y.

    sloan Guest

    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
     
    sloan, Nov 6, 2006
    #3
  4. Lastly (sorry for so long of a post), we're thinking about AJAX. My
    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]
     
    Flinky Wisty Pomm, Nov 6, 2006
    #4
  5. Steve Y.

    Michael Lang Guest

    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
     
    Michael Lang, Nov 6, 2006
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.