Business Logic in SQL Server CLR ? RRS feed

  • Question

  • We're building a three tier architecture whereas the client is a .net Windows
    Client (WPF), database is SQL Server 2008 and for the middle-tier we're using
    a WCF service. As for the business logic we're thinking (for different
    reasons) about putting it mainly to the database (stored procs and CLR).
    We're thinking about passing objects from the GUI through the service to the
    SQL Server CLR. For transport we will serialize the objects in binary format
    and pass them as SqlBinary to the CLR where we then deserialize the objects.
    We'll have main parts of our logic in the CLR but doing CRUDs using Transact
    Has anyone out there experince with this approach and can cover about pros
    and cons?
    Sunday, March 8, 2009 1:53 PM

All replies

  • Bad idea.

    Firstly, the architecture you have mentioned is a two tier not a three tier architecture.  I was involved in redesigning an VB/COM application that had winforms & sql server 2000 (with upto 1000 stored procedures) to .NET.  The only reason we are carrying over the same architecture is because the people that support the application are more of database developers and SQL coders than .NET coders.  So they ONLY understand SQL (not .NET).  We are not even gonna use WPF because it is too much of a learning curve for the team.

    I would recommend you to follow the architecture you mentioned only if you are in similar settings.  Your team understands and knows sql stored procs than managed code.

    A proper n-tier/3-tier architecture that has complex business logic will keep the core of the application in a rich language support to keep the maintenance, support and flexibility of the application better.

    { Gaja; }
    Pl mark if answer solves your problem | Visit http://gajakannan.com/netarch.aspx for .net ref Arch
    Monday, March 9, 2009 4:09 AM