View Full Version : .Net application architectures...

7th August 2003, 00:14
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.

7th August 2003, 06:06
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.

7th August 2003, 07:43
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.

7th August 2003, 08:26
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

7th August 2003, 10:05
Have we worked together before, DP? Im sure thats familiar... :D

7th August 2003, 12:50
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).

7th August 2003, 13:17
are good. no need to stay with com+. it just incurs overheads in talking to the runtime.

19th September 2003, 21:23
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 )

19th September 2003, 22:00
.net + SPs here - works fine as long as DBA is a reasonable person

24th September 2003, 18:30
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.

24th September 2003, 20:21
A good post on the subject.

I think there is not a "one size fits all" solution.

Also you are coming up against the relational - object mismatch that occurs when you try to bolt on a pure OO middle layer to a highly normalised relational back end.

For web apps it makes more sense to forget pure OO layers and make it much more procedural, stateless and scalable.

Personally I am a very good T-SQL programmer and concentrate all the business logic in complex SP's with error handling.

The BO layer is then nothing more than a transport mechanism between the presentation layer (usually ASP.NET databinding and custom controls)

This makes the .NET code thin and performance very good with well written SQL (I NEVER use cursors!) and correctly indexed tables (and views).

As for business rules (e.g. validation) if you put in the front end GUI you get responsive apps (don't need a round trip to validate data) but a maintenance problem. If you bury it ALL in the middle/back end, then every validation reqiures a round trip. You choose.

Just my tuppence worth,


29th September 2003, 13:54
The best vb/sql server developer I've ever worked with uses the same architecture - huge complex sp's and very little code anywhere else.

The next version of visual studio.net will iron out the few disadvantages with this architecture. You'll be able to write sp's in vb/c# and manage and maintain them from within the IDE.

For GUI stuff, I rely heavily on the Infragistics .Net controls.

I havn't done a webforms/asp.net project yet, but maybe in my next contract.

30th September 2003, 09:52
using complex procs for the business rules usually gives excellent performance up to a point but if you
ever need scalability then the BR's have got to be in the middle tier running under com+

where using application centre you can setup component load balancing and then if performance is a
problem just add another box, this is the way .NET arch. needs to go to compete with J2EE on large enterprise apps....

30th September 2003, 13:47
Why can't you use SQL Server clustering, federated databases, partitioned data and materialised views to increase performance?

I know what you are saying, but manipulating 100,000,000 rows of data on the middle tier is never going to run quickly even with 100 .Net middle tier servers.

Don't even suggest passing gigabytes of data between tiers using XML web services....