Click here to Skip to main content
15,890,512 members
Home / Discussions / Design and Architecture
   

Design and Architecture

 
AnswerRe: Multi-Tenant Architecture Pin
Pete O'Hanlon13-Jan-14 1:08
mvePete O'Hanlon13-Jan-14 1:08 
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 
Hi all!

I'm working on a UML / ER modeling tool, and I need some opinions.

My C# solution currently has the following projects/assemblies:

Core - defines basic stuff like logging, a hierarchy of elements (and operations on that hierarchy), what a model is, and that a model may contain model elements
Content - defines subclasses of model element, ie concrete stuff that a model may contain, like Class, Attribute, Table, Column, and how these elements relate to each other
Engine - defines operations on the content, for example building a model from an external file, conversion from conceptual model (classes) to ER-model (tables)
ViewModel - an MVVM implementation
Application - A WPF UI.

Random comments:
- Most classes in Core, Content and Engine are public, because ViewModel needs direct access to them.
- I want to somehow define Services provided by Engine. ViewModel will call these services.
- This will be a desktop solution, but I might want to make it browser-based later. Would it in that case make sense to implement the "services" using MCF, which I'm new to?
- I am currently not using interfaces (as in public interface IMyInterface {}) for the purpose of handling dependencies between assemblies.

So my "problem", then. Content references Core. Engine references Core and Content. ViewModel references Engine, Core and Content. This just doesn't seem like a working separation. I'm just now starting on the Application level, and I notice it will definitely reference ViewModel, but that I also potentially need to introduce elements to both Engine and ViewModel that should be available to ViewModel and Application (Commands and services). So I feel I need to redesign a bit. The question is whether to split more (create CommonXXX -assemblies containing, for example, interface declarations used by other assemblies) or to combine assemblies. I think combining in this case makes more sense, although I generally like to split things.

Engine operates directly on Core and Content objects, so it might make sense to combine these three into the same assembly, as they are really quite tightly integrated. In that case I could make all classes non-public, and publish them for ViewModel to use through interfaces. Then the question is whether these interfaces should be declared in a Common assembly or in the same assembly as where the implementing classes reside.

An attractive alternative to publishing the data objects using interfaces: I thought I might allow selective access to data objects and services through scripting, in which case I could have wrapper "API" objects (think Engine returns new ClassAPI(aClass)). These would be declared in the current Engine assembly, and the view model objects could then use those instead of the actual data objects defined in the Content assembly. Then I could implement a scripting language which could use reflection to access all the API objects' methods and properties. Using these API objects, I could easily publish, for both scripting and UI, any aspects of the core data classes (and "services" as methods) I want/need, and I would not need any separate interfaces, and there would be no need for currently public Core/Content/Engine classes to be public.

So, after a possible merge I would then have:
Core - Defining both data model and services, contains old Core, Content as well as Engine. Either the "API layer" or some sort of service implementation, or a combination of these, would be the only public view into this assembly.
Common - Stuff like Logging and genuinely commonly used items, possibly including interface declarations
ViewModel - Uses Core's API or service layer, and some Common elements
Application - the WPF UI

Sounds better, or does it?

If this admittedly superficial description evokes any kind of reactions, I'd really like to hear them Smile | :)

Cheers,

Kim
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 
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 

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.