If I had a viewmodel that looked something like this
public class AddressViewModel
{
public int AddressID {get;set;}
public string Street {get;set;}
public string Town {get;set;}
public SelectList Countries { get; set; }
}
How would I go about populating this?
Would it be 2 queries to the database, 1 to populate the address info and another to return all countries into the SelectList?
I think so yes, maybe even cache it if the list values don't change.
Related
I am trying to create an indexes for ProviderProfileId, Email, and Address1
I have created queries that work, but not indexes. I know the inheriting from List for the collections might be part of the problem. List is a carry over from when I had to do a significant amount of XmlSerialization on much older projects, and became a habit in my modeling. I also noticed that in Raven the serialization is much cleaner that if AddressCollection were just List. Any thoughts?
Model is similar to
public class Customer {
public string Id {get;set}
public string Name {get;set;}
public AddressCollection {get;set;}
public SocialMediaAliasCollection {get;set;}
}
public class SocialMediaAliasCollection:List<SocialMedialProfile>{}
public class SocialMediaProfile{
public string ProviderProfileId {get;set;}
public string Email {get;set;}
}
public class AddressCollection:List<Address>{}
public class Address{
public string Address {get;set;}
public string City {get;set;}
public string State {get;set;}
public string Zip {get;set;}
}
I now answered it, basically I didn't know linq well enough. Makes sense once I figured it out. I was trying to make an index for a sub collection, in this case addresses. Not 100% this works, but it does compile and when I push the index to the server it does not blow up.
Map = collection => from item in collection where item.AddressCollection != null
from item2 in item.AddressCollection
select new {
item2.city
}
How do you handle look up values with NHibernate? For example, I have an Order entity and it has a BillingAddress property that is a value object named Address, it's simple if the Address object just contains State and Country properties as strings. But what if I want a Country contains a list of its states the Order form can populate appropriate state dropdown list for each selected country.
Can I still create Country and State as value objects? Or they must be entities? And if they are entities, can Address be a value object?
Below is a sample code of my example:
public class Order
{
public virtual int OrderId { get; set; }
public virtual Address BillingAddress { get; set; }
}
public class Address
{
public virtual State State { get; set; }
public virtual Country Country { get; set; }
}
public class Country
{
public virtual string Name { get; set; }
public virtual ICollection<State> States { get; set; }
}
public class State
{
public virtual string Name { get; set; }
public virtual Country Country { get; set; }
}
If you want to store the lookup data in the database, then they need to be entities. Otherwise, it is up to you. If you do, I suggest marking them as immutable and putting them in a read only 2nd-layer cache.
If you store them as values, and they have multiple fields like Abbrevation, Name, Coordinates, etc. then you can save the id as a value in the data store, and have the lookup data hard-coded as a plain C# class. You'll just retrieve the id value from NHibernate, and then your calling code will have to run the lookup methods on the class. Not as elegant, but simplifies from the NHibernate/database perspective.
Either method is acceptable--it more depends on how you plan on using them: who is maintaining and using the code at each level, where you want the caching and/or lookup code, if you control the calling code or not, etc.
I'm working on a legacy MySql database and have the following entities:
public class Company
{
public int Id { get; set;}
public string Address { get; set; }
public string City { get; set; }
}
public class CompanyDepartment
{
public int Id { get; set;}
public string Address { get; set; }
public string City { get; set; }
}
The idea is that a company only use the department class if it has more than one department.
Right now I'm trying to make a company/department search, this means I need a list of all departments and therefore I need to "create" departments of all the companies that only has one department, and therefore don't have a entry in CompaynyDepartment.
To do this I was thinking of use components in fluent NHibernate, but I'm not sure I can join the real departments with the fake ones?
Is there a better approach to this problem? It's not an option to change the database structure.
I ended up changing the database structure
I'm using NHibernate in my web app and it is mapped with my database. I have a model, somthing like this:
public class Company {
public virtual string Name { get; set; }
public virtual IList<Employee> Employeers { get; set; }
}
public class Employee {
public virtual string Name { get; set; }
public virtual DateTime Birthday { get; set; }
/* other properties */
public virtual Company Company { get; set; }
}
PS: it's not real model but it works for my samples/doubts...
I'm using HQL to get my objects and I'd like to know if is there any way to:
1) Get a Company object and fill the Employeers Colletion with Top 10 Employeers Ordered by Birthday Desc ?
2) Is there any way to, when collection is filled, fill it with only some fields like Name and Birthday? I have a lot of properties that I won't use in my view. I can create a DTO for this but I don't know how to do!
Thanks
Persistent collections and entities represent the current state; they can't have just a part of that (think about it: if they did, how would NH track changes?)
So, in both cases, the answer is queries and DTOs. You can easily retrieve the data you need with HQL:
class EmployeeNameAndBirthDay
{
public string Name { get; set; }
public DateTime Birthday { get; set; }
}
public IList<EmployeeNameAndBirthDay> GetTopEmployees(Company company)
{
return session.CreateQuery(#"
select Name as Name,
Birthday as Birthday
from Employee
where Company = :company
order by Birthday desc
")
.SetParameter("company", company)
.SetMaxResults(10)
.SetResultTransformer(
Transformers.AliasToBean<EmployeeNameAndBirthDay>())
.List<EmployeeNameAndBirthDay>();
}
Given the database design below how would you model it? Address Type is Bussiness/Home etc and the PersonId is on Address table is because there are many addresses for one Person.
I would most do something like:
public class Person
{
public virtual int PersonId { get; set; }
public virtual string FirstName { get; set; }
public virtual string LastName{ get; set; }
public virtual DateTime DOB{ get; set; }
public virtual IList<Address> Addresses { get; set; }
}
public class Address
{
public virtual int AddressId{ get; set; }
public virtual Person Resident{ get; set; }
public virtual AddressType Location{ get; set; }
public virtual string PostalCode{ get; set; }
public virtual string FullAddress{ get; set; }
}
public class AddressType
{
public virtual int AddressTypeId{ get; set; }
public virtual string Description{ get; set; }
public virtual IList<Address> Addresses { get; set;}
}
however I have no idea if this is appropriate.
I have always done my models with objects and have never left int's in place. NHibernate Mapping will easily replace these with the objects and then lazy/eager load them, so I just figure this is the best option. Opinions?
The domain looks clean.
The only think I'd think twice about is the renaming of some property/column names, which can lead to confusion.
I would model it like it is in reality, Person has several addresses and each can be of a different type, leaving out all the database id fields. That will make your NHibernate Configurations and queries a little bit harder to create, but your domain model will be much easier to work with.
I suggest convert relations Address-Person and Address-AddressType to on way relations. It not very usable if each Address now its Person (resident) and each AddressType now its Address (addresses). By doing this your will be very simpler.
Additionally it seems meaningless to have a unique person for each address. Imagine you are saving some persons in your model that they are just one family that all together live in an one home. Consequently all of them have same address.
I would change the Address and AddressType many to one relationship. It is actually one-to-one and in which case, AddressType would go in the Address table as a field. That is the best form IMHO.