First of all I would like to say it is good to be back. I have been on non-CSLA projects for a while now and a new opportunity may let me continue where I left off. This is going to start off long-winded but I wanted to frame my need the best I could.
At a high level, this new opportunity was begun (before I started here) with the intention to be Object Oriented, have flexibility in deployment options and be maintainable. The team came to these goals after working on legacy systems that, well, were not. The promises of Object Oriented design/programming and CSLA lead them here to the path we have been on, however, underlying philosophies and practices of team individuals were not supportive of best practice implementation of Object Oriented coding and CSLA. Most of the remaining team now admit that the aspects of maintainability / performance trade-offs were ignored. So that is the summary of our history to arrive at the current dilemma…
The application, which performed decently in test and QA environments, now performs very poorly with a distant production database server whether we physically separate our code tiers or not. There are some things we know where we are at fault; multi-functional user stories turned into overly complex business objects and forms (code reuse won over lightweight objects), an only loose grasp of data transfer methods and their performance differences, and a deep and hierarchical object graph that accommodates a diverse set of behaviors. Even with all of that in our collective consciousness we are asking ourselves, "Has anyone seen an enterprise sized Object Oriented/CSLA appliaction that performs well?"
So, finally, I come to our question(s) for this community to help us move past the “Can OO*/CSLA... ?” question. Who has had success with the development, deployment and maintenance of an enterprise sized application? What are some usage statistics for your application? Some examples of what we’re looking for…
· The industry your application serves
· Size of the development team
· The number of concurrent/total users
· Size of database
·
Method of data transfer (All-In-One BO (like PT application) => Database OR DTO's, etc)
·
Describe most complex object graph (in general
terms of course) and it's perfomance issues/solutions
· Anything else that would loosely quantify a size:success ratio of your application (I know, this is a fuzzy discussion all on its own).
Looking back over this I realize I am asking a-lot from you. Hopefully some of you will see this as a help the community as well by getting
together a list of success stories and comparing each others usage demands.
Thanks in Advance,
Brian Strickland
- The industry your application serves
Banking- current app is system which handles the Trading, Settlement and Other associated Processing of various financial instruments, eg Options, Furtures, Swaps etc.
- Size of the development team
4 developers
- The number of concurrent/total users
Max 35 - we develop alongside our users, we turn ideas and bugs around very, very quickly releasing into UAT many times a day.
- Size of the database
Approx 500 tables
- Method of data transfer
BO mostly, dto where it is deemed appropriate.
- Describe most complex object graph
So far its our Custodian model (we have more complex ones to come).
Custodian (contains)
Branches --> Branch (contains)
Markets --> Market (contains)
Accounts --> Account (contains)
SSIs --> SSI
Clients --> Client (contains)
Nostros --> Nostro
We maintain this lot on a single (albeit complex) form (Windows). It works great!
A lot of inspiration for this was taken from Rockys deep data sample.
- Anything else..
All above done in 3.0.4, Looking to upgrade to 3.6 sooner rather than later.
· The industry your application serves
Semi-conductor fabrication
· Size of the development team
2 to 4
· The number of concurrent/total users
~30
· Size of database
multiple gig
· Method of data transfer (All-In-One BO (like PT application) => Database OR DTO's, etc)
Stored procs -> BO's
· Describe most complex object graph (in general terms of course) and it's perfomance issues/solutions
Multiple depth (arbitrary, using recursive objects) each with several collections of children. Each child in a collection could have several hundred properties (time series data).
· Anything else that would loosely quantify a size:success ratio of your application (I know, this is a fuzzy discussion all on its own).
App was written with CSLA 1.1 (customized) and upgraded to 1.4 by the time I left the company. It is still in use and a central tool for the company (going on 5+ years now).
The same bo's used for the application, were used to implements web services that allowed both data pull and push.
As I mentioned this was using older 1.x CSLA, and I have not been on that project for over a year. However that said, we had pretty good performance with this model. The data model was based on a tree where you had a single root object that could fan out to one or more child nodes. The depth was between 5 and 7 nodes deep. From memory the object model was something like:
Root Node
Child Node collection
Child Node
...
Child Node
Child Node collection
Child Node
Child Node
...
Additionally each child had a time series for allocations, which was a dynamic class with up to 150 time based properties (used a property bag, ITypedList, ICustomTypeDescriptor behind the scenes). We did some tricks to group changes of multiple time points with the same allocation value so that database updates were quick (this is where we found most of the performance issues).
strick9:
You said something that interested me. Describing your complex object, you said you had "recursive objects". Have these ever been a performance challenge?
Thanks,
Brian
· The industry your application serves
Networking Products Distribution
· Size of the development team
5
· The number of concurrent/total users
40 / 100; Windows Forms Clients running on workstations for local users and via Citrix for remote users.
· Size of database
~5GB
· Method of data transfer (All-In-One BO (like PT application) => Database OR DTO's, etc)
All-In-One BO
· Describe most complex object graph (in general terms of course) and it's perfomance issues/solutions
SalesOrder --> SalesOrderLine -->PricingCondition. No performance issues. Though overall we make extensive use of lazy loading of children when dealing with single parent objects; and when dealing with collections of parents, we use eager loading to load children.
· Anything else that would loosely quantify a size:success ratio of your application (I know, this is a fuzzy discussion all on its own).
From day one of go-live the client has been processing on average 500 orders per day, with an average of 20 detail lines (ranging from 1 detail line to a couple hundred).
· The industry your application serves
Industrial Rolling Stock Manufacture
· Size of the development team
4
· The number of concurrent/total users
30 / 80; Combination of Windows Forms Clienta and Intranet Web Client.
· Size of database
~5GB
· Method of data transfer (All-In-One BO (like PT application) => Database OR DTO's, etc)
All-In-One BO
· Describe most complex object graph (in general terms of course) and it's perfomance issues/solutions
A job (with material and labour allocations) can contain any number of child jobs; each child job (with its own material and labour allocations) can contain any number of child jobs, going down up to 15 levels. Though overall we make extensive use of lazy loading of children when dealing with single parent objects; and when dealing with collections of parents, we use eager loading to load children.
· Anything else that would loosely quantify a size:success ratio of your application (I know, this is a fuzzy discussion all on its own).
The application was developed at a time when the client's business was slow (processing around a 1000 jobs per day) around 5 years ago . This has since quadrupled and the app is taking it in its stride! Even in the beginning we did struggle with some some long-running processes timing out on the web client, resulting in all long-running processes (those in excess of a minute) being moved to a windows client.
Our application is being developed over several stages, it is eventually going to become a complete CRM, SFA and Accounting application but so far is limited to CRM & SFA.
· The industry your application serves
Generic CRM & SFA application, currently being used primarily in-house;
waiting for customer base to grow.
· Size of the development team
2-4 on this specific project at any time
· The number of concurrent/total users
20 users so far, but with expectations to scale to over 100.
· Size of database
Current database size is about 5GB and growing daily.
· Method of data transfer (All-In-One BO (like PT application) => Database OR DTO's, etc)
All-In-One BO
· Describe most complex object graph (in general terms of course) and it's perfomance issues/solutions
Haven't gotten any really complex objects at the moment, but are expecting so when we get into the financials
· Anything else that would loosely quantify a size:success ratio of your application (I know, this is a fuzzy discussion all on its own).
CSLA has become the standard for all new development within our organisation, because it is working so well for us. We currently have over 5 applications developed using it in some form or another, with many more to come! Couldn't imagine doing some of the things we have been able to do or want to do (i.e. application server scaling) without CSLA.
Copyright (c) Marimer LLC