Design patterns


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 2 of 2

Thread: Design patterns

  1. #1
    Ronadl Guest

    Design patterns


    Hey all,

    Just got done looking at an article on MSDN regarding a design pattern called
    Engine-Collection-class. You can find this featured on the MSDN Home page.
    I was curious what y'all thought of it and I wanted to add a few comments
    of my own, or ask a few questions. Here goes.

    This looks like a well thought out pattern but while it purports to be friendly
    for nTier development it also seems to be very stateful. Am I reading that
    correctly? Along these lines, statefulness seems to be a huge design no-no
    in COM+ development. Almost to the point that even a little is to be quickly
    designed out.

    We are writing our first distributed app within our IT shop, and we want
    to avoid many of the mistakes that can be made with a DNA application; Implementing
    this design pattern looks like it would be a mistake. Any opinions?

    In our search for help in designing the application, we have looked at Duwamish
    Books 4 and FMStocks, both of which seemed to be designed with scalability
    and performance first. My concern is that they are both relatively simple
    applications with only four or five objects, their OLTP style design would
    be easy to manage. But if the number of business objects you need are 15
    to 20, this design would have the performance but would be a bit of a nightmare
    to maintain, right? Duwamish has no discrete objects just a business layer
    performing business transactions, if you multiply the needed transaction
    methods times 10, these objects would resemble the client apps we're trying
    to replace, yuk. FMStocks 2000 at least groups the transaction methods in
    stateless objects (account related transactions in the Account object) but
    no real pattern (add, change, delete, update, fetch, search, etc)

    Does anybody feel strongly for a design pattern that would be a balance of
    maintainability and performance?

    Sorry to ramble, I'm been combing the web for days looking for a good balanced
    middle tier design for COM+... not much out there.

    rfp

  2. #2
    Yves Reynhout Guest

    Re: Design patterns

    Design patterns are nice, but should only be used to help you solve certain
    problems, not for the sake of having a design pattern in your application.

    "Ronadl" <rfphillips_remove_@pub.mcleodusa.com> wrote in message
    news:39beabe7$1@news.devx.com...
    >
    > Hey all,
    >
    > Just got done looking at an article on MSDN regarding a design pattern

    called
    > Engine-Collection-class. You can find this featured on the MSDN Home

    page.
    > I was curious what y'all thought of it and I wanted to add a few comments
    > of my own, or ask a few questions. Here goes.
    >
    > This looks like a well thought out pattern but while it purports to be

    friendly
    > for nTier development it also seems to be very stateful. Am I reading

    that
    > correctly? Along these lines, statefulness seems to be a huge design

    no-no
    > in COM+ development. Almost to the point that even a little is to be

    quickly
    > designed out.


    There's nothing against statefullness in COM+. You just need to be
    selective about where you use it. I wouldn't use this kind o' pattern for a
    Website/-application, but possibly for a Win32 client oriented application.

    > We are writing our first distributed app within our IT shop, and we want
    > to avoid many of the mistakes that can be made with a DNA application;

    Implementing
    > this design pattern looks like it would be a mistake. Any opinions?
    >
    > In our search for help in designing the application, we have looked at

    Duwamish
    > Books 4 and FMStocks, both of which seemed to be designed with scalability
    > and performance first. My concern is that they are both relatively simple
    > applications with only four or five objects, their OLTP style design would
    > be easy to manage. But if the number of business objects you need are 15
    > to 20, this design would have the performance but would be a bit of a

    nightmare
    > to maintain, right?


    The size of your application (in terms of BO) shouldn't be a concern, but
    every phase of your development cycle should.

    > Duwamish has no discrete objects just a business layer
    > performing business transactions, if you multiply the needed transaction
    > methods times 10, these objects would resemble the client apps we're

    trying
    > to replace, yuk. FMStocks 2000 at least groups the transaction methods in
    > stateless objects (account related transactions in the Account object) but
    > no real pattern (add, change, delete, update, fetch, search, etc)


    Well, patterns are nice in an object-oriented environment, not in a
    service-oriented environment. Believe me, developing for MTS/COM+ is more
    about service-oriented than object-oriented.

    > Does anybody feel strongly for a design pattern that would be a balance of
    > maintainability and performance?
    >
    > Sorry to ramble, I'm been combing the web for days looking for a good

    balanced
    > middle tier design for COM+... not much out there.
    >
    > rfp


    Best Reg.,
    Yves Reynhout - http://www.orbidsmartx.com



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center