• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

.Net application architectures...

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    .Net application architectures...

    A quick poll... how are people organising their apps?

    An app im building at the moment:

    1) SQL Backend with SPs.

    2) COM+ Data Access Objects that make use of the MS Data Access Application Block thingy to call the SPs, and return custom Business Entities that internally contain scalar values, or a strongly typed dataset (depending on the type of data the application handles is instance or set based), which is passed between layers. If required, these can serialise to XML / SOAP.

    Authorisation checking is performed in this layer - e.g. you can never get to data without being authorised and if neccessary that can be done close to a security database.

    3) One or more COM+ Business Logic Objects that call the DAO's and handle transactions.

    4) A facade that handles authentication as required and then calls the relevant BLO.

    And then slap on a webservice, webforms or winforms client GUI.


    Any better ways of organising this? The downside of the above is the custom business entities have to be given a strong name and installed in the GAC on the Data Access, Business Object and Client tiers.

    #2
    Sounds pretty good to me

    but why are you organising your components as COM+ components ( as opposed to straightforward unserviced .NET assemblies ) ? Unless you desperately need serviced components and support for object pooling , managed transactions etc. , I'd normally tend to leave the business layer components as simple .NET assemblies to keep deployment and support simple . Of course , it really depends on the nature of your objects . As an example the complete MS Application Block Data layer does not need to be a COM+ component at all and works just fine as a simple .NET assembly without any overheads.

    Also I think using the MS Data Application block is a great idea. I use it all the time myself and it takes the pain out of long parameter lists in stored procs. You might also want to look at the exception handling block which I have also found very useful and almost every application can benefit from it.

    Also if this is a commercial product , I think strong naming and installation in the GAC is well worth it as it is much easier to slap on a module that uses the same classes later on without too much truck with versioning hell.

    Comment


      #3
      Re: Sounds pretty good to me

      The Application Blocks are very useful - there are also ones for Exception handling, Configuration and Caching, which I am looking to work into the app.

      Its a .Net rewrite of a document management system I had created previously - Im using this as a template application of sorts.

      Im using COM+ as its pretty much a habit id got in to - from using MTS to manage objects to using COM+ for JIT and object pooling, and possibly role based security (hasnt been decided on yet for this app). The app is using a single SQL Server DB, so I dont strictly need distributed transactions, but, the Business Object Layer controls transactions that involve multiple Data Access Layer objects, and this seemed the simplest way to enlist them.

      Any other strategies for this? In this case the layers may potentially be on several machines, say 3 for Business Objects and 2 for Data Access, at this stage its all on one box.

      Comment


        #4
        Re: Sounds pretty good to me

        My advice is to write it as large spaghetti PHP blocks with no error handling and all SQL embedded in the pages as hardcoded strings.

        Make sure you use mySql which is pathetic with no transactional or stored procedure capability and then call it an Open Source masterpiece. :rollin

        Comment


          #5
          Re: Sounds pretty good to me

          Have we worked together before, DP? Im sure thats familiar...

          Comment


            #6
            Its wise to read up on your competitors once in a while

            Mysql now has transaction support. From their website:-

            MySQL Standard includes the standard MySQL storage engines and the InnoDB storage engine. InnoDB is a transaction-safe, ACID-compliant storage engine with commit, rollback, crash recovery and row-level locking capabilities.

            Stored procedures are also on their way but there are other features that are higher priority (nested selects are a useful addition).

            Comment


              #7
              the application blocks

              are good. no need to stay with com+. it just incurs overheads in talking to the runtime.

              Comment


                #8
                Drop COM

                According to Francesco Balena
                it is not intended for .net to be built on top of COM.
                It was just done that way to get the product out of the door.
                p18 of Programming Microsoft Visual Basic .NET

                ( very nice book by the way even for somebody like
                me who does not much like basic these days )

                Comment


                  #9
                  Re: Drop COM

                  .net + SPs here - works fine as long as DBA is a reasonable person

                  Comment


                    #10
                    .Net Architecture best practices

                    There are not enough good books or articles on .Net architectures, especially for straight-forward winform apps. As I work alone, it's something I'd be very interested in discussing with more experienced members of this forum.

                    Be warned, what follows is a rambling brain dump.

                    My last project was a big distributed database app with a very rich GUI.

                    I used the MS Data Access Block as a standard .Net assembly on the server, (with my own wrapper around it to make interaction with the object layer loosely coupled), talking to SQL Server or MSDE (via stored procedures) depending on the size of the customer (MSDE sufficed very impressively for most of my customers - and not requiring a SQL Server licence was a very big advantage given our pricing plan).

                    Data was passed back to the object layer on the client machine using either datareaders or datasets. It then populated objects, and forwarded them to the UI layer. I far prefer this method to passing datasets as I don't like my UI layers to contain any references to data entities.

                    Error reporting, licensing and application update modules all took advantage of webservices.

                    My current project is a far smaller desktop app. I have no data layer at all, all my objects simply inherit from a base class with LoadXML and SaveXML methods, using XML serialisation to persist my objects to the client's machine. Having no database and no data issues is wonderful, it's made programming the rest of the app so much easier.

                    One of my weaknesses in previous projects and with previous languages, has been letting business logic and code in general creep onto the front-end. Validation logic and things like that. With this project I've explicitly tried to avoid that.

                    First I started using databinding but found there are a number of inherent flaws within the .Net databinding and controls that make it impossible to use for complex front-ends.

                    I'm now using User Interface Process components as an extra layer inbetween the UI and Object layers. There's a MS application block for UIP's but I prefer to use my own. I'm very pleased with them and will always use them from now on I reckon. My front-end layers are very thin and have no code in them that doesn't relate strictly to presentation, and conversely, my objects have nothing in them that relates to presentation.

                    I will use webservices for error reporting, licensing and application updates again.

                    A former colleague is getting good results from Rocky's CSLA, but I'm still not sure. Most of my projects are rich GUI clients rather than enterprise apps.

                    Another former colleague designs his SQL Server database structure, then uses his own .Net tool to auto-generate the data access layer (using MS's block as a template) and object layer. He then uses databinding on the front-end to bind his objects to his controls.
                    I'm not convinced by it though - his front-ends are very limited - anything that draws on multiple objects is very hard for him to do. It's only ideal for simply dialog based apps where one form displays the data for one object.

                    Also, good relational db design does not nec. translate directly to good object design. It means his objects are as normalized as his tables.

                    Another issue I'm finding in .Net architectures is to what extent to use stored procedures. Some people put most of their business logic in them - using cursors, triggers etc, whereas I try and avoid using them for anything other than simple CRUD. If you put business logic in them, then you have to go to two places to debug and maintain your logic. If it's all in the Object layer, you lose the efficiency of sprocs but increase ease of maintainence.

                    Very sorry for the rambling post. It's something that interests me a great deal tho - I'm still undecided about what are the best practices for these kinds of .net app.

                    Thoughts welcome.

                    Comment

                    Working...
                    X