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()orGetById()?
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.
1
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.
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