n-tier design and when to add additional assemblies
-
Hi to everybody, I've been asked to assist with designs for a large enterprise scale accounting project. So far I have decided upon a n-tier design with remotable objects and webservices at the server end. I'd like to gauge the responses from everybody as to when you believe the middle and even UI layers should be split up into their own assemblies. I am aware of the performance penalties associated with reflection vs. native object calls, but am also firmly believe that a large scale application will sooner or later use reflection in some way, shape or form. Based on this, my initial thoughts are to split the application into logical functional units. So following these lines of thought (and these are rough thoughts), an assembly for business objects (BO), interfaces (I), data components (DC) and user interface (UI). Each of the BO, I, DC and UI will then be replicated for each logical unit: ie. debtors, creditors, stock, general ledger, system, etc. I'd love to hear your thoughts on this and any suggestions and/or recommendations you've got. Thanks in advance.
Edward Steward edwardsteward@optusnet.com.au
-
Hi to everybody, I've been asked to assist with designs for a large enterprise scale accounting project. So far I have decided upon a n-tier design with remotable objects and webservices at the server end. I'd like to gauge the responses from everybody as to when you believe the middle and even UI layers should be split up into their own assemblies. I am aware of the performance penalties associated with reflection vs. native object calls, but am also firmly believe that a large scale application will sooner or later use reflection in some way, shape or form. Based on this, my initial thoughts are to split the application into logical functional units. So following these lines of thought (and these are rough thoughts), an assembly for business objects (BO), interfaces (I), data components (DC) and user interface (UI). Each of the BO, I, DC and UI will then be replicated for each logical unit: ie. debtors, creditors, stock, general ledger, system, etc. I'd love to hear your thoughts on this and any suggestions and/or recommendations you've got. Thanks in advance.
Edward Steward edwardsteward@optusnet.com.au
Edward Steward wrote:
I have decided upon a n-tier design
What a lot of people don't realise is that all designs are n-tier. I presume you mean n-tier where n >= 3
Edward Steward wrote:
when you believe the middle and even UI layers should be split up into their own assemblies
Yes, they should. Unless it is for a very small application. You've already mentioned this is an enterprise application so they should be separated out.
Edward Steward wrote:
Based on this, my initial thoughts are to split the application into logical functional units.
"logical functional units" is a very overloaded term. No two people seem to use it the same way. What do you mean by that?
Upcoming events: * Edinburgh: Web Security Conference Day for Windows Developers (12th April) * Glasgow: Introduction to AJAX (2nd May), SQL Server, Mock Objects My website
-
Hi to everybody, I've been asked to assist with designs for a large enterprise scale accounting project. So far I have decided upon a n-tier design with remotable objects and webservices at the server end. I'd like to gauge the responses from everybody as to when you believe the middle and even UI layers should be split up into their own assemblies. I am aware of the performance penalties associated with reflection vs. native object calls, but am also firmly believe that a large scale application will sooner or later use reflection in some way, shape or form. Based on this, my initial thoughts are to split the application into logical functional units. So following these lines of thought (and these are rough thoughts), an assembly for business objects (BO), interfaces (I), data components (DC) and user interface (UI). Each of the BO, I, DC and UI will then be replicated for each logical unit: ie. debtors, creditors, stock, general ledger, system, etc. I'd love to hear your thoughts on this and any suggestions and/or recommendations you've got. Thanks in advance.
Edward Steward edwardsteward@optusnet.com.au
Oops... I hit post instead of "Quote Selected Text"
Edward Steward wrote:
an assembly for business objects (BO), interfaces (I), data components (DC) and user interface (UI).
Or even multiple assemblies for each part. For exampe. Will you really have only one UI to allow the user to interface with the enterprise application? Or will they access it via a web application, or windows application or mobile application depending on the scenario?
Edward Steward wrote:
Each of the BO, I, DC and UI will then be replicated for each logical unit: ie. debtors, creditors, stock, general ledger, system, etc.
Is that really the best way? When thinking about the UI you should be thinking along the lines of what tasks the user has to complete. What is the goal of the users? Don't force them into starting one UI for half their task and then switch to another UI in order for them to complete it.
Upcoming events: * Edinburgh: Web Security Conference Day for Windows Developers (12th April) * Glasgow: Introduction to AJAX (2nd May), SQL Server, Mock Objects My website
-
Edward Steward wrote:
I have decided upon a n-tier design
What a lot of people don't realise is that all designs are n-tier. I presume you mean n-tier where n >= 3
Edward Steward wrote:
when you believe the middle and even UI layers should be split up into their own assemblies
Yes, they should. Unless it is for a very small application. You've already mentioned this is an enterprise application so they should be separated out.
Edward Steward wrote:
Based on this, my initial thoughts are to split the application into logical functional units.
"logical functional units" is a very overloaded term. No two people seem to use it the same way. What do you mean by that?
Upcoming events: * Edinburgh: Web Security Conference Day for Windows Developers (12th April) * Glasgow: Introduction to AJAX (2nd May), SQL Server, Mock Objects My website
Colin, > I presume you mean n-tier where n >= 3 Yes this is true. > "logical functional units" is a very overloaded term. No two people seem to use it the same way. What do you mean by that? By "logical functional units" I refer to debtors, creditors, stock, general ledger, system, etc. > Will you really have only one UI to allow the user to interface with the enterprise application No this will be accessible from a variety of platforms > Don't force them into starting one UI for half their task and then switch to another UI in order for them to complete it No intention of it. As you can probably see from the above points you have raised my thoughts aren't altogether clear on the topic, so I think it best to elaborate on some of the finer points of the "current design". · Main application (EXE). Minimal code and almost a "stub" making reference to various UI assemblies. · A common UI assembly to be used as a control library as well as base forms · A common interface assembly handling some of the typical/common CRUD operations · A common BO assembly for common validation code, error checking, "business base" objects, etc. · A dedicated DAL assembly which all DC assemblies can hook to. The chosen DAL model I have used previously on a smaller project with much success. This has plenty of support for ALL sql db operations. · A business rules assembly to be used for custom attributes. Again have used something very similar before with much success. · Debtors - DC, I, BO, UI · Creditors - DC, I, BO, UI · Stock - etc, etc. I hope this paints a clearer picture for you and I do appreciate your input. Thanks
Edward Steward edwardsteward@optusnet.com.au
-
Colin, > I presume you mean n-tier where n >= 3 Yes this is true. > "logical functional units" is a very overloaded term. No two people seem to use it the same way. What do you mean by that? By "logical functional units" I refer to debtors, creditors, stock, general ledger, system, etc. > Will you really have only one UI to allow the user to interface with the enterprise application No this will be accessible from a variety of platforms > Don't force them into starting one UI for half their task and then switch to another UI in order for them to complete it No intention of it. As you can probably see from the above points you have raised my thoughts aren't altogether clear on the topic, so I think it best to elaborate on some of the finer points of the "current design". · Main application (EXE). Minimal code and almost a "stub" making reference to various UI assemblies. · A common UI assembly to be used as a control library as well as base forms · A common interface assembly handling some of the typical/common CRUD operations · A common BO assembly for common validation code, error checking, "business base" objects, etc. · A dedicated DAL assembly which all DC assemblies can hook to. The chosen DAL model I have used previously on a smaller project with much success. This has plenty of support for ALL sql db operations. · A business rules assembly to be used for custom attributes. Again have used something very similar before with much success. · Debtors - DC, I, BO, UI · Creditors - DC, I, BO, UI · Stock - etc, etc. I hope this paints a clearer picture for you and I do appreciate your input. Thanks
Edward Steward edwardsteward@optusnet.com.au
Edward Steward wrote:
A common UI assembly to be used as a control library as well as base forms
You might want to split that out further based on platform (e.g. win forms assembly and webforms assembly). You might also want to separate the controls out - I find that useful as it puts up an additional barrier to stop me accidentally creating circular references between forms and controls. Forms should know about their controls. Controls should know nothing about the form. Separating the controls into their own assembly means that if you find yourself needing to reference the assembly with the forms then you know you've got part of the design wrong.
Edward Steward wrote:
DC assemblies
Sorry, I don't see a definition for "DC". Data Controller/Connector?
Edward Steward wrote:
The chosen DAL model I have used previously on a smaller project with much success. This has plenty of support for ALL sql db operations.
Fair enough - but be careful about scalability. It might scale well, or you might need to alter the design to allow it to scale well.
Edward Steward wrote:
· Debtors - DC, I, BO, UI · Creditors - DC, I, BO, UI · Stock - etc, etc.
This can work well, but if you have circular dependencies it can start to become difficult to maintain. e.g. What happens if you have an entity that is both a Creditor and Debtor? The only thing I'm not so sure about is the fact that you have all those pillars with the UI sitting on top of each - Are they just controls? I would imaging that the UI (the forms) would make a roof to fit on top of the pillars.
Upcoming events: * Edinburgh: Web Security Conference Day for Windows Developers (12th April) * Glasgow: Introduction to AJAX (2nd May), SQL Server, Mock Objects My website
-
Edward Steward wrote:
A common UI assembly to be used as a control library as well as base forms
You might want to split that out further based on platform (e.g. win forms assembly and webforms assembly). You might also want to separate the controls out - I find that useful as it puts up an additional barrier to stop me accidentally creating circular references between forms and controls. Forms should know about their controls. Controls should know nothing about the form. Separating the controls into their own assembly means that if you find yourself needing to reference the assembly with the forms then you know you've got part of the design wrong.
Edward Steward wrote:
DC assemblies
Sorry, I don't see a definition for "DC". Data Controller/Connector?
Edward Steward wrote:
The chosen DAL model I have used previously on a smaller project with much success. This has plenty of support for ALL sql db operations.
Fair enough - but be careful about scalability. It might scale well, or you might need to alter the design to allow it to scale well.
Edward Steward wrote:
· Debtors - DC, I, BO, UI · Creditors - DC, I, BO, UI · Stock - etc, etc.
This can work well, but if you have circular dependencies it can start to become difficult to maintain. e.g. What happens if you have an entity that is both a Creditor and Debtor? The only thing I'm not so sure about is the fact that you have all those pillars with the UI sitting on top of each - Are they just controls? I would imaging that the UI (the forms) would make a roof to fit on top of the pillars.
Upcoming events: * Edinburgh: Web Security Conference Day for Windows Developers (12th April) * Glasgow: Introduction to AJAX (2nd May), SQL Server, Mock Objects My website
Colin, > Common UI Point taken > "DC". Data Controller/Connector Data components > DAL Noted. > Circular references My thoughts on this is to try and loosely reference varying projects/assemblies as required by using [Assembly].Load instead of "hard" referencing the projects at design time. > UI as roof Yes the UI for the pillars would consist of a series of forms that are specific to the type of pillar - debtors, creditors, etc. Edward
Edward Steward edwardsteward@optusnet.com.au
-
Colin, > Common UI Point taken > "DC". Data Controller/Connector Data components > DAL Noted. > Circular references My thoughts on this is to try and loosely reference varying projects/assemblies as required by using [Assembly].Load instead of "hard" referencing the projects at design time. > UI as roof Yes the UI for the pillars would consist of a series of forms that are specific to the type of pillar - debtors, creditors, etc. Edward
Edward Steward edwardsteward@optusnet.com.au
Edward Steward wrote:
My thoughts on this is to try and loosely reference varying projects/assemblies as required by using [Assembly].Load instead of "hard" referencing the projects at design time.
As you noted earlier, there are performance hits against using reflection here. If you want your application to scale efficiently, then you have to be very careful how and when you use Assembly.Load.
Deja View - the feeling that you've seen this post before.