Well, this sounds easier than it is! I have a table that contains amount stored as string values. But my code needs them as decimal values and it needs them to be casted to decimal as part of the query that IQueryable is making! Thus, the use of .ToList() is not possible. The cast needs to be done by the database behind it.
This IQueryable is basically part of a chain on IQueryables so a next query might want to add a filter on this amount to make a smaller selection, or do other kinds of math with the amount. The query that goes in might already be a subselection of all data.
Edit: Let me explain what I am working on here: I have something like this method to write:
public static IQueryable<PriceList> GetPriceList(this IQueryable<PriceData> query) => query.Select(d => new PriceList{Name = d.Item.Name, Price = decimal.Parse(d.Value)}).AsQueryable();
And PriceData is a record containing a few fields and the prices as string values. But the PriceList record needs them as Decimal.
This method could then be used by another extension method for further selections, math and whatever. It's just that decimal.parse and other options don't work within an IQueryable...
As already commented, what you are trying to do is not supported.
Your best bet is to change your database field type to what it actualy represents: Money/Decimal
If that is not possible, talk to the person, which has the ability to make it possible
If that is not possible, the closest workaround I can imagine is:
public class PriceList
{
public string Price { get; set; }
public decimal ParsedPrice => decimal.Parse(Price);
}
And then:
.Select(d=>new PriceList
{
Price = d.Price
});
However, you can't execute any DbOperations on ParsedPrice then. Also note that you can't use a Constructor with parameters in EF6. That would be the next problem you would encounter.
EF works best for CRUD. For everything more you probably should have a Service, which is fetching the data only you need, materialize them and make a DTO or Businessobject out of it.
Something like that:
public class MyService
{
public IEnumerable<PriceList> GetPriceList(Expression<Func<MyEntity, bool>> predicate)
{
var data = _context.MyEntity.Where(predicate).ToList();
foreach (var item in data)
{
var dto = new PriceList {...}
yield return dto;
}
}
}
Related
Background
We have a table, let's call it Files.
We have certain attributes on the row, such as Name, CreatedDate, etc.
We have a blob column with the contents of the file, FileBytes.
So our model looks similar to:
public class FileEntity
{
public string Name { get; set; }
public DateTime CreatedDate { get; set; }
public byte[] FileBytes { get; set; }
// many other fields, most of which we'd like to use
}
Goal
On certain queries, we only care about whether FileBytes is null, not anything about the bytes themselves.
We'd like to be able to query and have a field in our model class populated, say, FileHasBytes that is a bool.
We'd like this field to exist only in our class, so that we can refer to it in the webapp as part of the model.
We'd like to be able to query for this bool value without pulling the full bytes from the field.
Question
How can I, using EF6, define a field on my model class that will be consistently projected, based on another field in the table, without pulling the full contents of that field?
Considered Options / Workarounds
Computed column: we were hoping to avoid this because it seems unnecessary
View: We'd also like to avoid this because it seems unnecessary to go to this for a single column
Projection to a new object: This is doable, but we'd like to be able to map directly without selecting a new object each time, including all of the fields that go with it.
With the current version of EF6 you can't do exactly what you are after.
There are other alternatives, but with all of them you'd have to make compromises on the goals stated above. Such as either using a new projected type with the computed property, or not querying on the computed value and be explicit on the condition instead, etc.
However, using something like DelegateDecompiler it might be possible to have the model and query just as you are expecting.
Something along the lines of:
[Computed]
public bool HasFileBytes
{
get { return FileBytes != null; }
}
And in your query you'd use the .Decompile() call to get that translated:
var query = ctx.Files
.Where(x => x.HasFileBytes)
.Decompile();
Using Linq.Translations could be another similar alternative.
source: http://www.daveaglick.com/posts/computed-properties-and-entity-framework
This is not ideal but I think you can add a static property that returns QueryExpression like
public static Expression<Func<FileEntity,bool>> FileHasBytes
{
get { return ((c)=> c.FileBytes != null && SqlFunctions.DataLength(c.FileBytes)>0)
}
I have not tried this code, so take this with grain of salt, so try and test it thoroughly.
I have used some thing like this using Dynamic.linq some time ago, but not tried it lately
dbContext.FileEntities.Where("FileHasBytes == true"),
My domain model has a lot of complex financial data that is the result of fairly complex calculations on multiple properties of various entities. I generally include these as [NotMapped] properties on the appropriate domain model (I know, I know - there's plenty of debate around putting business logic in your entities - being pragmatic, it just works well with AutoMapper and lets me define reusable DataAnnotations - a discussion of whether this is good or not is not my question).
This works fine as long as I want to materialize the entire entity (and any other dependent entities, either via .Include() LINQ calls or via additional queries after materialization) and then map these properties to the view model after the query. The problem comes in when trying to optimize problematic queries by projecting to a view model instead of materializing the entire entity.
Consider the following domain models (obviously simplified):
public class Customer
{
public virtual ICollection<Holding> Holdings { get; private set; }
[NotMapped]
public decimal AccountValue
{
get { return Holdings.Sum(x => x.Value); }
}
}
public class Holding
{
public virtual Stock Stock { get; set; }
public int Quantity { get; set; }
[NotMapped]
public decimal Value
{
get { return Quantity * Stock.Price; }
}
}
public class Stock
{
public string Symbol { get; set; }
public decimal Price { get; set; }
}
And the following view model:
public class CustomerViewModel
{
public decimal AccountValue { get; set; }
}
If I attempt to project directly like this:
List<CustomerViewModel> customers = MyContext.Customers
.Select(x => new CustomerViewModel()
{
AccountValue = x.AccountValue
})
.ToList();
I end up with the following NotSupportedException: Additional information: The specified type member 'AccountValue' is not supported in LINQ to Entities. Only initializers, entity members, and entity navigation properties are supported.
Which is expected. I get it - Entity Framework can't convert the property getters into a valid LINQ expression. However, if I project using the exact same code but within the projection, it works fine:
List<CustomerViewModel> customers = MyContext.Customers
.Select(x => new CustomerViewModel()
{
AccountValue = x.Holdings.Sum(y => y.Quantity * y.Stock.Price)
})
.ToList();
So we can conclude that the actual logic is convertible to a SQL query (I.e., there's nothing exotic like reading from disk, accessing external variables, etc.).
So here's the question: is there any way at all to make logic that should be convertible to SQL reusable within LINQ to entity projections?
Consider that this calculation may be used within many different view models. Copying it to the projection in each action is cumbersome and error prone. What if the calculation changes to include a multiplier? We'd have to manually locate and change it everywhere it's used.
One thing I have tried is encapsulating the logic within an IQueryable extension:
public static IQueryable<CustomerViewModel> WithAccountValue(
this IQueryable<Customer> query)
{
return query.Select(x => new CustomerViewModel()
{
AccountValue = x.Holdings.Sum(y => y.Quantity * y.Stock.Price)
});
}
Which can be used like this:
List<CustomerViewModel> customers = MyContext.Customers
.WithAccountValue()
.ToList();
That works well enough in a simple contrived case like this, but it's not composable. Because the result of the extension is an IQueryable<CustomerViewModel> and not a IQueryable<Customer> you can't chain them together. If I had two such properties in one view model, one of them in another view model, and then the other in a third view model, I would have no way of using the same extension for all three view models - which would defeat the whole purpose. With this approach, it's all or nothing. Every view model has to have the exact same set of calculated properties (which is rarely the case).
Sorry for the long-winded question. I prefer to provide as much detail as possible to make sure folks understand the question and potentially help others down the road. I just feel like I'm missing something here that would make all of this snap into focus.
I did a lot of research on this the last several days because it's been a bit of a pain point in constructing efficient Entity Framework queries. I've found several different approaches that all essentially boil down to the same underlying concept. The key is to take the calculated property (or method), convert it into an Expression that the query provider knows how to translate into SQL, and then feed that into the EF query provider.
I found the following libraries/code that attempted to solve this problem:
LINQ Expression Projection
http://www.codeproject.com/Articles/402594/Black-Art-LINQ-expressions-reuse and http://linqexprprojection.codeplex.com/
This library allows you to write your reusable logic directly as an Expression and then provides the conversion to get that Expression into your LINQ query (since the query can't directly use an Expression). The funny thing is that it'll be translated back to an Expression by the query provider. The declaration of your reusable logic looks like this:
private static Expression<Func<Project, double>> projectAverageEffectiveAreaSelector =
proj => proj.Subprojects.Where(sp => sp.Area < 1000).Average(sp => sp.Area);
And you use it like this:
var proj1AndAea =
ctx.Projects
.AsExpressionProjectable()
.Where(p => p.ID == 1)
.Select(p => new
{
AEA = Utilities.projectAverageEffectiveAreaSelector.Project<double>()
});
Notice the .AsExpressionProjectable() extension to set up projection support. Then you use the .Project<T>() extension on one of your Expression definitions to get the Expression into the query.
LINQ Translations
http://damieng.com/blog/2009/06/24/client-side-properties-and-any-remote-linq-provider and https://github.com/damieng/Linq.Translations
This approach is pretty similar to the LINQ Expression Projection concept except it's a little more flexible and has several points for extension. The trade off is that it's also a little more complex to use. Essentially you still define your reusable logic as an Expression and then rely on the library to convert that into something the query can use. See the blog post for more details.
DelegateDecompiler
http://lostechies.com/jimmybogard/2014/05/07/projecting-computed-properties-with-linq-and-automapper/ and https://github.com/hazzik/DelegateDecompiler
I found DelegateDecompiler via the blog post on Jimmy Bogard's blog. It has been a lifesaver. It works well, is well architected, and requires a lot less ceremony. It does not require you to define your reusable calculations as an Expression. Instead, it constructs the necessary Expression by using Mono.Reflection to decompile your code on the fly. It knows which properties, methods, etc. need to be decompiled by having you decorate them with ComputedAttribute or by using the .Computed() extension within the query:
class Employee
{
[Computed]
public string FullName
{
get { return FirstName + " " + LastName; }
}
public string LastName { get; set; }
public string FirstName { get; set; }
}
This can also be easily extended, which is a nice touch. For example, I set it up to look for the NotMapped data annotation instead of having to explicitly use the ComputedAttribute.
Once you've set up your entity, you just trigger decompilation by using the .Decompile() extension:
var employees = ctx.Employees
.Select(x => new
{
FullName = x.FullName
})
.Decompile()
.ToList();
You can encapsulate logic by creating a class that contains the original Entity and the additional calculated property. You then create helper methods that project to the class.
For example, if we were trying to calculate the tax for an Employee and a Contractor entity, we could do this:
//This is our container for our original entity and the calculated field
public class PersonAndTax<T>
{
public T Entity { get; set; }
public double Tax { get; set; }
}
public class PersonAndTaxHelper
{
// This is our middle translation class
// Each Entity will use a different way to calculate income
private class PersonAndIncome<T>
{
public T Entity { get; set; }
public int Income { get; set; }
}
Income calculating methods
public static IQueryable<PersonAndTax<Employee>> GetEmployeeAndTax(IQueryable<Employee> employees)
{
var query = from x in employees
select new PersonAndIncome<Employee>
{
Entity = x,
Income = x.YearlySalary
};
return CalcualateTax(query);
}
public static IQueryable<PersonAndTax<Contractor>> GetContratorAndTax(IQueryable<Contractor> contractors)
{
var query = from x in contractors
select new PersonAndIncome<Contractor>
{
Entity = x,
Income = x.Contracts.Sum(y => y.Total)
};
return CalcualateTax(query);
}
Tax calculation is defined in one place
private static IQueryable<PersonAndTax<T>> CalcualateTax<T>(IQueryable<PersonAndIncome<T>> personAndIncomeQuery)
{
var query = from x in personAndIncomeQuery
select new PersonAndTax<T>
{
Entity = x.Entity,
Tax = x.Income * 0.3
};
return query;
}
}
Our view model projections using the Tax property
var contractorViewModel = from x in PersonAndTaxHelper.GetContratorAndTax(context.Contractors)
select new
{
x.Entity.Name,
x.Entity.BusinessName
x.Tax,
};
var employeeViewModel = from x in PersonAndTaxHelper.GetEmployeeAndTax(context.Employees)
select new
{
x.Entity.Name,
x.Entity.YearsOfService
x.Tax,
};
I'm trying to create a way to make an unique search into the database and build the right object for my needs. I mean, I use a SQL query that returns me a lot of rows and then I build the collections based on that database rows. E.g.:
We have a table called People and another table called Phones.
Let's suppose that this is my SQL query and will return the following below:
SELECT
P.[Id], P.[Name], PH.[PhoneNumber]
FROM
[dbo].[People] P
INNER JOIN
[dbo].[Phones] PH ON PH.[Person] = P.[Id]
And that's the results returned:
1 NICOLAS (123)123-1234
1 NICOLAS (235)235-2356
So, my class will be:
public interface IModel {
void CastFromReader(IDataReader reader);
}
public class PhoneModel : IModel {
public string PhoneNumber { get; set; }
public PhoneModel() { }
public PhoneModel(IDataReader reader) : this() {
CastFromReader(reader);
}
public void CastFromReader(IDataReader reader) {
PhoneNumber = (string) reader["PhoneNumber"];
}
}
public class PersonModel : IModel {
public int Id { get; set; }
public string Name { get; set; }
public IList<PhoneModel> Phones { get; set; }
public PersonModel() {
Phones = new List<PhoneModel>();
}
public PersonModel(IDataReader reader) : this() {
CastFromReader(reader);
}
public void CastFromReader(IDataReader reader) {
Id = Convert.ToInt32(reader["Id"]);
Name = (string) reader["Name"];
var phone = new PhoneModel();
phone.CastFromReader(reader);
Phones.Add(phone);
// or
Phones.Add(new PhoneModel {
PhoneNumber = (string) reader["PhomeNumber"]
});
}
}
This code will generate a PersonModel object with two phone numbers. That's good so far.
However, I'm struggling to make some good way to deal when I want to manage more tables with this process.
Let's suppose, then, I have a new table called Appointments. It stores the user's appointments to the schedule.
So, adding this table to the query, the result will be:
1 NICOLAS (123)123-1234 17/09/2014
1 NICOLAS (123)123-1234 19/09/2014
1 NICOLAS (123)123-1234 27/09/2014
1 NICOLAS (235)235-2356 17/09/2014
1 NICOLAS (235)235-2356 19/09/2014
1 NICOLAS (235)235-2356 17/09/2014
As you guys can see, the problem is to manage the phones and the appointments this way. Do you can think in anything that could solve this issue?
Thank you all for the opinions!
You cannot transfer your query result to strongly typed objects without first defining these objects' types. If you want to keep query data in memory, I recommend that you transfer it into objects of a previously defined type at some point.
What follows is therefore not something that I would actually recommend doing. But I want to demonstrate to you a possibility. Judge for yourself.
As I suggested in a previous comment, you can mimick strongly typed DTOs using the Dynamic Language Runtime (DLR), which has become available with .NET 4.
Here is an example for a custom DynamicObject type that provides a seemingly strongly-typed façade for a IDataReader.
using System.Data;
using System.Dynamic; // needs assembly references to System.Core & Microsoft.CSharp
using System.Linq;
public static class DataReaderExtensions
{
public static dynamic AsDynamic(this IDataReader reader)
{
return new DynamicDataReader(reader);
}
private sealed class DynamicDataReader : DynamicObject
{
public DynamicDataReader(IDataReader reader)
{
this.reader = reader;
}
private readonly IDataReader reader;
// this method gets called for late-bound member (e.g. property) access
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
int index = reader.GetOrdinal(binder.Name);
result = index >= 0 ? reader.GetValue(index) : null;
return index >= 0;
}
}
}
Then you can use it like this:
using (IDataReader reader = someSqlCommand.ExecuteReader(…))
{
dynamic current = reader.AsDynamic(); // façade representing the current record
while (reader.Read())
{
// the magic will happen in the following two lines:
int id = current.Id; // = reader.GetInt32(reader.GetOrdinal("Id"))
string name = current.Name; // = reader.GetString(reader.GetOrdinal("Name"))
…
}
}
But beware, with this implementation, all you get is a façade for the current record. If you want to keep data of several records in memory, this implementation won't help a lot. For that purpose, you could look into several further possibilities:
Use anonymous objects: cachedRecords.Add(new { current.Id, current.Name });. This is only any good if you access the cachedRecords in the same method where you build it, because the anonymous type used will not be usable outside of the method.
Cache current's data in an ExpandoObject.
If you want to manually write a data type for each combination of columns resulting from your queries, then you have a lot of work to do, and you will end up with lots of very similar, but slightly different classes that are hard to name. Note also that these data types should not be treated as something more than what they are: Data Transfer Objects (DTOs). They are not real domain objects with domain-specific behaviour; they should just contain and transport data, nothing else.
What follows are two suggestions, or ideas. I will only scratch at the surface here and not go into too many details; since you haven't asked a very specific question, I won't provide a very specific answer.
1. A better approach might be to determine what domain entity types you've got (e.g. Person, Appointment) and what domain value types you have (e.g. Phone Number), and then build an object model from that:
struct PhoneNumber { … }
partial interface Person
{
int Id { get; }
string Name { get; }
PhoneNumber PhoneNumber { get; }
}
partial interface Appointment
{
DateTime Date { get; }
Person[] Participants { get; }
}
and then have your database code map to these. If, for example, some query returns a Person Id, Person Name, Phone Number, and an Appointment Date, then each attribute will have to be put into the correct entity type, and they will have to be linked together (e.g. via Participants) correctly. Quite a bit of work. Look into LINQ to SQL, Entity Framework, NHibernate or any other ORM if you don't want to do this manually. If your database model and your domain model are too different, even these tools might not be able to make the translation.
2. If you want to hand-code your data query layer that transforms data into a domain model, you might want to set up your queries in such a way that if they return one attribute A of entity X, and entity X has other attributes B, C, and D, then the query should also return these, such that you can always build a complete domain object from the query result. For example, if a query returned a Person Id and a Person Phone Number, but not the Person Name, you could not build Person objects (as defined above) from the query because the name is missing.
This second suggestion will at least partially save you from having to define lots of very similar DTO types (one per attribute combination). This way, you can have a DTO for a Person record, another for a Phone Number record, another for an Appointment record, perhaps (if needed) another for a combination of Person and Phone Number; but you won't need to distinguish between types such as PersonWithAllAttributes, PersonWithIdButWithoutNameOrPhoneNumber, PersonWithoutIdButWithPhoneNumber, etc. You'll just have Person containing all attributes.
I have a class:
public class BigClass
{
public int Id { get; set; }
public string Name { get; set; }
...
public List<LittleClass> LittleClassList { get; set; }
}
Is it possible to return List of its instances in one request to DataBase? This approach invokes many requests to DataBase:
List<BigClass> data = context.Table1_Name ...
foreach(var item in data)
{
item.LittleClassList = context.Table2_Name ...
}
Lambda syntax is preferred. Thank you.
from big in context.TableA
from little in big.LittleClassList
select little;
And in extension format
Context.TableA.Where(...).SelectMany(x=>x.LittleClassList);
List<LittleClass> littleClassesOfListBigClasses = new List<LittleClass>();
context.BigClass.ToList().ForEach(e=>littleClassesOfListBigClasses.AddRange(e.LittleClassList));
Specialy for Dave A.
What I think OP wants:
He want to take all LittleClasses stored in db by one lambda-expression.
Explanation about how does my code works:
1) I use EF(entity framework). If you dont know what it is you can read information
here. In the question I see that the OP knows what is EF and how to use it, so I didnt find a need to explain.
2) I take all data from table BigClass from the DB and bring it as List(in 1 query)
3) I used ForEach(from Linq) to go through the returned BigClass list and add the all LittleClasses to the littleClassesOfListBigClasses
Notice also you can add Where before to ToList to get not all data stored in BigClass table but only a part, it will look something like this:
context.BigClass.Where(some lambda-expression).ToList()
So my answer is clear now?
in sql I have a table like:
PersonOrganisationRole
which has the columns:
PersonId, OrganisationId RoleId
So it's a three way table between Person, Organisation and Role.
So I was wanting to create a way to get all the Organisations a Person belongs to:
public class Person
{
public IEnumerable<Organisation> Organisations
{
get
{
var organisations = new List<Organisation>();
foreach (var personOrganisationRole in PersonOrganisationRoles.Where(personOrganisationRole => !organisations.Contains(personOrganisationRole.Organisation)))
{
organisations.Add(personOrganisationRoles.Organisation);
}
return organisations;
}
}
}
So I'm basically populating a list by iterating through all items in the table and only adding the org if I haven't added it already. This is important because there could be multiple rows in the table with the same PersonId and OrganisationId due to the fact a person could have multiple roles at an organisation.
I'm thinking though there must be a far better way of writing this code.
Any suggestions?
You can use LINQ's Distinct operator to do this unique-collecting, and ToList to collect the results in a list:
return PersonOrganisationRoles
.Distinct(x => x.Organisation)
.ToList();
public IEnumerable<Organisation> Organisations
{
get
{
return PersonOrganisationRoles
.Select(por => por.Organisation)
.Distinct()
.ToList();
}
}
You will want to check that Organisation implements
GetHashcode and Equals properly
Optionally implements IEquatable<Organisation>
Distinct uses these to establish whether the item is already in the collection. (Contains did the same in the original sample, so that's probably what you intended)
A combination of the Linq Select() and Distinct() methods should do it.
var organisations = PersonOrganisationRoles
.Select<PersonOrganisationRoles,Organisation>(p => p.Organisation )
.Distinct();
Make it a function rather than property.
We are used to write objectInstance.PropertyName and usually think that this is fast operation that accesses some piece of data that is already in memory. In your case any call to Person.Organizations involves some processing and maybe even IO operations.
The other, possibly more important, point is that when I do:
var a = myPerson.Organizations;
var b = myPerson.Organizations;
I expect that a is pointing to the same List<> instance in memory as b.
And in your code that is not true. So please change the property to function or cache the result in private property so that processing is done only once. Like this:
public class Person
{
private IEnumerable<Organisation> organizations;
public IEnumerable<Organisation> Organisations
{
get
{
if (organizations != null) return organizations;
organisations = new List<Organisation>();
// fill list here
return organisations;
}
}
}