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 wonder 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 and 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 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.
Lets 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. so I have:
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 it's 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.
- Lets say that now I have a report that needs the Person and Children data, should it too 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 that my Repository can implement some interfaces too and that there are Transaction to be considered. I know it's too much to ask and I'd really appreciate offers of good reads on those subjects can't be answered here.
Thanks!
Aucun commentaire:
Enregistrer un commentaire