I just started out a new job as a C# programmer on .NET 3.5. My manager gives me total independence on how I build my modules, which is generally a good thing, but there are minuses too. Having too much "freedom" tends to make me wander to places you wouldn't have if you had some strict guidance. My project involves many simple forms and reports, usually one table for each form, sometimes I have a *1-to-1* or *1-to-Many* relations on a specific form. Also, my business objects are not complicated for now, every table on the database maps to on exactly one business object. So, I did my research and decided that for my DAL which isn't too complicated I'll be using a Linq-to-SQL within simple Repositories classes as it provides me with a *simple* ORM mappings of objects. Also. in .NET 3.5, I felt it's my best option (you are more than welcome to correct me if I'm wrong i.e if you can achieve ORM advantages with vanilla ADO.NET). I then decided that I'll be using an MVP pattern to tie up my layers, giving me a well de-coupled UI/Business Logic. Having said all that, theory worked perfect but soon as I started with my first module many questions arise. I don't want to make this question too general so I'll give a real life example and explain my confusions once at a time, trying to keep it as concise as I can. Let's say that I have a simple form that needs to present a `Person` details, and on that form on a button click a sub-form will popup with that person `Children`. Table Person: id(PK),name Table Children: id(PK),name,parent Corresponding to those tables I have the following objects: public class Person { [Column(IsPrimaryKey = true, IsDbGenerated = true)] public int id { get; set; } [Column] public string Name { get; set; } [Association...](Association Details) } public class Children { [Column(IsPrimaryKey = true, IsDbGenerated = true)] public int id { get; set; } [Column] public string Name { get; set; } [Association...](Association details). } To get Data from my models I have created a class `PersonRepository`. This class is in charge of querying the Database and fetch all the data that the `PersonView` needs, all done by Linq-to-SQL. public class PersonRepository { private readonly MyDatabaseContext db; public PersonRepository() { db = new MyDatabaseContext(); // Using 1 context } public IQueryable<Person> GetPerson(int id) { return from p in db.Person where p.id == id select p; } } Confusions on this `Repository` class: - How many of this repositories should I have, for each Table? Entity? Form? set for Forms? Is there any convention on that part? - The second form needs the `Person` `Children` details. Does that means it'll get a copy of the same `PersonRepository` object? - Is it correct to create an **online** context that lives throughout the lifetime of the Repository? What are the trade-offs, when should I use the disconnected approach? Here is my `PersonPresenter` constructor: public PersonPresenter { IPersonView view, PersonRepository repo } Here is my `ChildrenPresenter` constructor: public ChildrenPresenter { IChildrenView view, PersonRepository repo } As you can see I'm using same PersonRepository on the ChildrenPresenter. Here are more thoughts: - In simple cases like this should I just use one presenter for both forms? Or is it better to have one `Presenter` per form? - What if a form suddenly introduces a new Entity data to be taken from another table which belongs on a different `Repository`? What should I do then to get that data? As I said at the moment I don't have this case but I just wonder. - Let's say that now I have a report that needs the `Person` and `Children` data. Should it also use the same `PersonRepository` which means that from now on it's the central `Repository` for a `Person`? As you can see, I am pretty much bedazzled by all the paths I can take. I know that it's all a matter of experience and time but I do want to accelerate my knowledge. I know my DAL implementation is missing out on Transactions and that Repositories uses interfaces, but I have no idea how should I go about it.