General App Design Questions
-
These questions are more about validating how I create apps. I know how I like to do things, but I'm curious how the rest of you do it, so feel free to critique or post suggestions. I created a playground WPF app for tracking projects. The purpose of this app is primarily to play around and learn. In it I have UI, Entities, DAL, and BL projects. In the DB I created Company, Client, and Project tables. The Projects table has FK's for 3 lookup tables. See the pic here[^] My project entity looks like this
public class ProjectEntity : _EntityBase
{
public int ClientId { get; set; }
public int ProjectTypeId { get; set; }
public int ProjectStatusId { get; set; }
public int PayTypeId { get; set; }
public string ProjectName { get; set; }
public DateTime? EstStartDate { get; set; }
public DateTime? ActualStartDate { get; set; }
public DateTime? EstEndDate { get; set; }
public DateTime? ActualEndDate { get; set; }
public bool? IsActive { get; set; }
public decimal PayRate { get; set; }
}Ok, now for the questions: 1) Would you have your entity objects maintain references to other entities, or just the PK? For example, in the ProjectEntity I have ProjectTypeId which stores a reference to the Project Type row in lkpProjectTypes. When I get a project entity, should I create and store a ProjectType entity on it, or just the PK? What I usually do is store the PK of the lookup table, then call a method in the DL to get the lookup entity when it's needed. But I could make the GetProject method in the DL create related object when its called. The problem is that now you have a heavy object when you may not always need the child objects. 2) Similar to #1. When you create an instance of the ProjectEntity, would you create a ClientEntity and store it on the ProjectEntity instance? If so, do you then go up the logical tree and create a CompanyEntity to store on the ClientEntity which is stored on the ProjectEntity? Conversely, if you create a ClientEntity, do you store a list of ProjectEntities on always? If all I want is to display the Client's name, then getting a fully loaded ClientEntity seems like overkill. 3) How do you handle nulls, both in the DB and in the app? I'v heard some folks sa
-
These questions are more about validating how I create apps. I know how I like to do things, but I'm curious how the rest of you do it, so feel free to critique or post suggestions. I created a playground WPF app for tracking projects. The purpose of this app is primarily to play around and learn. In it I have UI, Entities, DAL, and BL projects. In the DB I created Company, Client, and Project tables. The Projects table has FK's for 3 lookup tables. See the pic here[^] My project entity looks like this
public class ProjectEntity : _EntityBase
{
public int ClientId { get; set; }
public int ProjectTypeId { get; set; }
public int ProjectStatusId { get; set; }
public int PayTypeId { get; set; }
public string ProjectName { get; set; }
public DateTime? EstStartDate { get; set; }
public DateTime? ActualStartDate { get; set; }
public DateTime? EstEndDate { get; set; }
public DateTime? ActualEndDate { get; set; }
public bool? IsActive { get; set; }
public decimal PayRate { get; set; }
}Ok, now for the questions: 1) Would you have your entity objects maintain references to other entities, or just the PK? For example, in the ProjectEntity I have ProjectTypeId which stores a reference to the Project Type row in lkpProjectTypes. When I get a project entity, should I create and store a ProjectType entity on it, or just the PK? What I usually do is store the PK of the lookup table, then call a method in the DL to get the lookup entity when it's needed. But I could make the GetProject method in the DL create related object when its called. The problem is that now you have a heavy object when you may not always need the child objects. 2) Similar to #1. When you create an instance of the ProjectEntity, would you create a ClientEntity and store it on the ProjectEntity instance? If so, do you then go up the logical tree and create a CompanyEntity to store on the ClientEntity which is stored on the ProjectEntity? Conversely, if you create a ClientEntity, do you store a list of ProjectEntities on always? If all I want is to display the Client's name, then getting a fully loaded ClientEntity seems like overkill. 3) How do you handle nulls, both in the DB and in the app? I'v heard some folks sa
Kevin Marois wrote:
- Would you have your entity objects maintain references to other entities, or just the PK? For example, in the ProjectEntity I have ProjectTypeId which stores a reference to the Project Type row in lkpProjectTypes. When I get a project entity, should I create and store a ProjectType entity on it, or just the PK?
I'm passing the integers around that represent the PK; a list of integers is simple, has little overhead and makes debugging easy. It's also not a large amount of "work" to fetch an ActiveRecord object based on it's
handle.Kevin Marois wrote:
- Similar to #1. When you create an instance of the ProjectEntity, would you create a ClientEntity and store it on the ProjectEntity instance? If so, do you then go up the logical tree and create a CompanyEntity to store on the ClientEntity which is stored on the ProjectEntity? Conversely, if you create a ClientEntity, do you store a list of ProjectEntities on always? If all I want is to display the Client's name, then getting a fully loaded ClientEntity seems like overkill.
It would add some complexity to ensure that you don't waste too much resources. I do not see many additional benefits to this approach though.
Kevin Marois wrote:
- How do you handle nulls, both in the DB and in the app? I'v heard some folks say never store nulls. I don't agree with that, but I'd like to hear your thoughts.
I think people should use arguments to defend their one-liners. It is said that a normalized database does not allow for "empty" values; on the other hand, the database-server provides you with the option. In practice, it's easier (and cleaner) to have a nullable field, than it is to have a new set of facts.
Bastard Programmer from Hell :suss:
-
These questions are more about validating how I create apps. I know how I like to do things, but I'm curious how the rest of you do it, so feel free to critique or post suggestions. I created a playground WPF app for tracking projects. The purpose of this app is primarily to play around and learn. In it I have UI, Entities, DAL, and BL projects. In the DB I created Company, Client, and Project tables. The Projects table has FK's for 3 lookup tables. See the pic here[^] My project entity looks like this
public class ProjectEntity : _EntityBase
{
public int ClientId { get; set; }
public int ProjectTypeId { get; set; }
public int ProjectStatusId { get; set; }
public int PayTypeId { get; set; }
public string ProjectName { get; set; }
public DateTime? EstStartDate { get; set; }
public DateTime? ActualStartDate { get; set; }
public DateTime? EstEndDate { get; set; }
public DateTime? ActualEndDate { get; set; }
public bool? IsActive { get; set; }
public decimal PayRate { get; set; }
}Ok, now for the questions: 1) Would you have your entity objects maintain references to other entities, or just the PK? For example, in the ProjectEntity I have ProjectTypeId which stores a reference to the Project Type row in lkpProjectTypes. When I get a project entity, should I create and store a ProjectType entity on it, or just the PK? What I usually do is store the PK of the lookup table, then call a method in the DL to get the lookup entity when it's needed. But I could make the GetProject method in the DL create related object when its called. The problem is that now you have a heavy object when you may not always need the child objects. 2) Similar to #1. When you create an instance of the ProjectEntity, would you create a ClientEntity and store it on the ProjectEntity instance? If so, do you then go up the logical tree and create a CompanyEntity to store on the ClientEntity which is stored on the ProjectEntity? Conversely, if you create a ClientEntity, do you store a list of ProjectEntities on always? If all I want is to display the Client's name, then getting a fully loaded ClientEntity seems like overkill. 3) How do you handle nulls, both in the DB and in the app? I'v heard some folks sa
Kevin Marois wrote:
Would you have your entity objects maintain references to other entities, or just the PK?
Depends on the nature of the objects and how they are used in the rest of the code.
Kevin Marois wrote:
The
problem is that now you have a heavy object when you may not always need the child objects.Yes that is the problem. First however it must in fact be 'heavy' in terms of the production system. So 10 rows isn't 'heavy' but one million certainly is. And if a sub entity represents 100 meg of data then even 10 of them is too many. But for the one million case it would always need to do a deferred look up. For larger ranges with more moderately sized (much smaller sub entities) it depends on actual data and how it will be used.
Kevin Marois wrote:
When you create an instance of the ProjectEntity, would you create a ClientEntity and store it
on the ProjectEntity instance? If so, do you then go up the logical tree and create a CompanyEntity to store
on the ClientEntity which is stored on the ProjectEntity?That question doesn't make much sense to me. A 'company' seems likes an owner. You can't create an owned object until you create the owner. And you shouldn't even allow for that possibility. Thus in the GUI the user must select a 'company' before doing anything with a owned object.
Kevin Marois wrote:
- How do you handle nulls, both in the DB and in the app
I handle them as nulls. Presumably for the "app" you mean in the data object. If you mean system wide then the question is wrong because they way a business object deals with nulls is different than how the GUI deals with them.