Click here to Skip to main content
15,900,511 members
Home / Discussions / Design and Architecture
   

Design and Architecture

 
AnswerRe: Multi-Tenant Architecture Pin
jschell13-Jan-14 9:22
jschell13-Jan-14 9:22 
AnswerRe: Multi-Tenant Architecture Pin
John D. Sanders5-Mar-14 11:17
John D. Sanders5-Mar-14 11:17 
GeneralRe: Multi-Tenant Architecture Pin
Nitin Singh India12-Mar-14 20:56
Nitin Singh India12-Mar-14 20:56 
QuestionTribalwars, Travian, and similar browser games Pin
AhmedMSedeek7-Jan-14 4:57
AhmedMSedeek7-Jan-14 4:57 
AnswerRe: Tribalwars, Travian, and similar browser games Pin
Marco Bertschi12-Jan-14 5:39
protectorMarco Bertschi12-Jan-14 5:39 
AnswerRe: Tribalwars, Travian, and similar browser games Pin
jschell12-Jan-14 9:11
jschell12-Jan-14 9:11 
QuestionI need to rethink my app structure, anyone care to comment? Pin
Kim Johnsson6-Jan-14 3:15
Kim Johnsson6-Jan-14 3:15 
AnswerRe: I need to rethink my app structure, anyone care to comment? Pin
Keld Ølykke20-Jan-14 10:39
Keld Ølykke20-Jan-14 10:39 
Hi Kim,

It is a bit difficult to give you some concrete advice, but here are my thoughts. I think they are classic 3 tier'ish.

The easiest is the lower layer aka the data layer e.g. a simple API that stores data types in a storage (memory, disk, db, whatnot). This can certainly be within its own project (with its own unit tests) - it doesn't need commands or similar. For abstract data classes, etc. I prob. would make a "Core" namespace within this project.

Another easy layer is the top layer aka the UI layer. Whether or not you tie the Application together with the UI layer in 1 assembly/package is a flexibility matter. In any case I would probably make a "Core" namespace within this layer too, but it has nothing to do with the data layer classes - only the UI.

The hardest part is how you design control from the top layer to the data layer and how the top layer is updated indirectly by updates in the data layer. In MVC its the C, in SOA it is the services. I would create a middle layer aka the service layer that knows the data layer, but doesn't know the UI layer. In here you can make a lot of Controllers e.g. Commands that modifies the data layer. If you have a pull design, you can make some poll/query commands too. If you have a push design, you can register a general listener pattern that the UI layer can use, or fire commands going upwards to be consumed by the UI layer (not so popular in these client-server days). This middle layer also will have its own "Core" namespace with abstract Commands and whatnot.

In above way you have a very clean division. It is pretty simple to avoid dependencies from the data layer to others, and it is doable to avoid a dependency from the control layer to the UI layer. One thing to consider is, if the UI layer should have direct access to the data layer. I find this decision hard to make - many cons and pros.

If it makes sense for you to have a common assembly then go make that and let the 3 layers depend on that. Otherwise, just pull in logging, etc. in each layer. A common layer can easily mud your clean dependencies; before you know it there is a utility class that knows how to calculate some business data and it is used by both the UI and the Data layer.


I hope it makes sense and triggered some thoughts.

Kind Regards,
Keld Ølykke
QuestionC# teamwork coding style Pin
comiscience5-Jan-14 23:09
comiscience5-Jan-14 23:09 
AnswerRe: C# teamwork coding style Pin
Eddy Vluggen6-Jan-14 12:42
professionalEddy Vluggen6-Jan-14 12:42 
GeneralRe: C# teamwork coding style Pin
comiscience6-Jan-14 20:19
comiscience6-Jan-14 20:19 
GeneralRe: C# teamwork coding style Pin
Eddy Vluggen7-Jan-14 9:27
professionalEddy Vluggen7-Jan-14 9:27 
GeneralRe: C# teamwork coding style Pin
comiscience7-Jan-14 20:41
comiscience7-Jan-14 20:41 
AnswerRe: C# teamwork coding style Pin
Pete O'Hanlon7-Jan-14 22:46
mvePete O'Hanlon7-Jan-14 22:46 
GeneralRe: C# teamwork coding style Pin
comiscience7-Jan-14 23:02
comiscience7-Jan-14 23:02 
QuestionBase class method access VS. abstract class Method access Pin
netfed4-Jan-14 22:28
netfed4-Jan-14 22:28 
AnswerRe: Base class method access VS. abstract class Method access Pin
Kornfeld Eliyahu Peter5-Jan-14 2:14
professionalKornfeld Eliyahu Peter5-Jan-14 2:14 
GeneralRe: Base class method access VS. abstract class Method access Pin
netfed5-Jan-14 3:01
netfed5-Jan-14 3:01 
AnswerRe: Base class method access VS. abstract class Method access Pin
Kornfeld Eliyahu Peter5-Jan-14 3:17
professionalKornfeld Eliyahu Peter5-Jan-14 3:17 
AnswerRe: Base class method access VS. abstract class Method access Pin
Shameel6-Jan-14 3:53
professionalShameel6-Jan-14 3:53 
GeneralRe: Base class method access VS. abstract class Method access Pin
netfed9-Jan-14 2:49
netfed9-Jan-14 2:49 
GeneralRe: Base class method access VS. abstract class Method access Pin
Richard MacCutchan9-Jan-14 4:43
mveRichard MacCutchan9-Jan-14 4:43 
AnswerRe: Base class method access VS. abstract class Method access Pin
Shameel10-Jan-14 3:36
professionalShameel10-Jan-14 3:36 
GeneralRe: Base class method access VS. abstract class Method access Pin
netfed12-Jan-14 0:51
netfed12-Jan-14 0:51 
GeneralRe: Base class method access VS. abstract class Method access Pin
Ron Beyer12-Jan-14 4:33
professionalRon Beyer12-Jan-14 4:33 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.