2

The question how-do-you-organize-your-projects already has a few good answers. I would like to get a better understanding about this suggested structure:

MyApp.Core
MyApp.Model
MyApp.Presenter
MyApp.Persistence
MyApp.UI
MyApp.Validation
MyApp.Report
MyApp.Web

Assuming MyApp is a winforms rich client to administer students, courses, rooms and teachers

Lets say i have a winforms user control to edit course information (name of the course, who teaches it, in which room and which students did register for the course). The class below reflects all the information i need for the user control

public class CourseDetails{
    public int Id{ get; set;}
    public Course Course{ get; set;}
    public Teacher Teacher{get; set;}
    public Room Room{get; set;}
    public List<Student> StudentList{get; set;}
}

Where would you put this class?

Methods of MyApp.Model

I would like to know how complex or simple the classes inside the namespace MyApp.Model shoud be.

Should the project MyApp.Model only contain very simple classes like

public class Course{
    public int CourseId{ get; set;}
    public string CourseName{ get; set;}
    public int CategoryId {get; private set;}

}
public class Teacher{
    public int TeacherId{ get; set;}
    public string TeacherName{ get; set;}
}

or should MyApp.Model contain also

  • complex classes like CourseDetails
  • additional methods for each class like Save() or GetById() ?

Additional topics

Where (in which project) should interfaces be implemented and where should base classe be used.

When should this additional methods (Save(), GetById()) be inherited from a base class or be contained in the class which implents an interface that has all the methods for saving and selecting.

public class CourseDetails: ModelBase{
    ...
}

public class ModelBase{
    public bool Save() {
        Console.WriteLine("do something clever to save each entity");
        return true;
    }
}

Sorry for not beeing more clear; I would like to understand what kind of things (classes, interfaces, ressources, etc) should be put in which project and why. I hope you get the idea.

2

The structure you are outlining here is called an onion architecture, also known as ports and adapters or hexagon architecture.

The principle is that you have the application core, and then you can put on layers outside this core, such as a UI layer, a persistence layer, a service layer and so on.

You define the interfaces for your application in your core and then you let the outer layers implement them. In this way your core stays "pure" and if you for instance want to change out your persistence mechanism from MySQL to MongoDB, it's a matter of reimplementing your persistence interface defined in core, in another module that is specific to MongoDB.

See: http://alistair.cockburn.us/Hexagonal+architecture and http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

for a more in depth explanation.

1

It Depends

The answer for this of course depends on several factors:

  • will any of the project binaries be shared across applications?
  • will any of the project binaries be pluggable?
  • does the application have multiple tiers?

If the application is stand-alone, the best option may be to have a single, self-contained exe, as it provides an extremely simple and easy deployment model - xcopy. In this case, organization of files is done through folders inside a single project.

This sounds in-line with your application description, assuming that the web portion is composed of client code meant to interface with a separate data store for the class administration data.

In a multi-tier application, you may need 1+ binaries for each tier and additional binaries for any types shared across tiers.

In general, though, I wouldn't split up projects unless there is a need to - YAGNI.

  • 1
    In this case I don't agree with the YAren'tGNI approach. Separation of concerns is far easier to achieve and keep up when unrelated code is in separate assemblies. And of course separation of concerns helps achieving better design with high cohesion and low coupling. Having to add an assembly in your references makes dependencies visible and makes it harder for dependencies "to creep up on you". Use it to think about whether you actually need that code and/or whether is is where it belongs. It's a LOT simpler to code this way than having to loosen badly intertwined dependencies when YAreGNI. – Marjan Venema Jul 19 '14 at 9:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.