|
Make sure you've got a reference to the System.Core assembly, and using System.Linq; at the top of your file.
Also, your types don't match. The error message reports a type of ClientAddress , whereas your predicate is looking at a type called ClientAddressEntity . You'll need to change the filters to be Expression<Func<Falcon.DAL.Data_Context.ClientAddress, bool>> .
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Same error.
And, even after adding a ref to System.Core, in the DAL code Core' is not found in System namespace.
This is bizarre.
If it's not broken, fix it until it is
|
|
|
|
|
Sorry, I just spotted that your types don't match and updated my answer. Your filters are looking at the ClientAddressEntity type, whereas your table contains ClientAddress objects.
Your filters need to be:
Expression<Func<Falcon.DAL.Data_Context.ClientAddress, bool>>
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That did it!
Many thanks
If it's not broken, fix it until it is
|
|
|
|
|
i have codin knap sack on c # and exe file
|
|
|
|
|
Leave it round the back. I'll pick it up in the morning.
|
|
|
|
|
Do not repost - it's rude, it wastes time, and it annoys people.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
|
It's the haiku version!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Do you have a question?
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
i have coding knap sack in c# and exe file
|
|
|
|
|
But the elephant flies at midnight.
Yuri, is that you? Do you have the microfilm?
|
|
|
|
|
The fora are dark
the fora are deep
but I have promises to keep
and miles to go before I sleep
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
Da.... the rooster barks at midnight. Look out for the elf.
I lost the microfilm comrade. I left it in some knapsack.
|
|
|
|
|
This is not a good question - we cannot work out from that little what you are trying to do.
Remember that we can't see your screen, access your HDD, or read your mind.
Edit your question and provide better information.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
If you're looking for the knapsack problem[^], there's pseudocode for a simple solution on wikipedia.
|
|
|
|
|
Is there a question somewhere?
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
I am considering a change to the way I return objects from my DAL. I would like your opinion on this design.
Currently each method in the DAL returns void, an Entity, or a List<[SomeEntity]>. So as an example, my AddLookup method looks like this:
public LookupEntity AddLookup(LookupEntity entity)
{
using (FMGDataContext dc = getDataContext())
{
var lookupExists = dc.Lookups.Where(l => l.Caption.Trim().ToLower() == entity.Caption.Trim().ToLower() &&
l.LookupCode.Trim().ToLower() == entity.LookupCode.Trim().ToLower()).Any();
if (!lookupExists)
{
Lookup newLookup = new Lookup
{
LookupCode = entity.LookupCode,
LookupTypeName = entity.LookupTypeName,
Caption = entity.Caption,
Description = entity.Description,
ParentId = entity.ParentId ?? 0,
};
dc.Lookups.InsertOnSubmit(newLookup);
try
{
dc.SubmitChanges();
entity.Id = newLookup.LookupId;
}
catch (Exception e)
{
}
}
else
{
throw new DuplicateLookupException(string.Format("Lookup {0} already exists", entity.Caption));
}
}
return entity;
}
Instead, I'm considering changing all my methods to return an instance of a response object:
public class _ResponseBase
{
[DataMember]
public Result Result { get; set; }
[DataMember]
public string Message { get; set; }
private Exception _Exception;
[DataMember]
public Exception Exception
{
get { return _Exception; }
set
{
if (_Exception != value)
{
_Exception = value;
Message = _Exception.Message;
Result = Result.Failure;
}
}
}
}
So now the AddLookup method would be:
public AddLookupResponse AddLookup(LookupEntity entity)
{
AddLookupResponse response = new AddLookupResponse();
using (FalconDataContext dc = getDataContext())
{
bool exsits = (from l in dc.Lookups
where l.LookupCode.Trim().ToLower() == entity.LookupCode.Trim().ToLower()
select l).Any();
if (exsits)
{
response.Result = Result.Failure;
response.Message = string.Format("Lookup code '{0}' already exists in the Lookups table", entity.LookupCode);
}
else
{
Lookup newRecord = new Lookup
{
LookupCode = entity.LookupCode,
LookupName = entity.LookupName,
Caption = entity.Caption,
Description = entity.Description,
SystemCode = entity.SystemCode,
ParentId = entity.ParentId
};
dc.Lookups.InsertOnSubmit(newRecord);
try
{
dc.SubmitChanges();
entity.Id = newRecord.LookupId;
response.Data = entity;
}
catch (Exception e)
{
response.Exception = e;
}
}
}
return response;
}
There are some good advantages of this design:
1. The ability to return more robust data & information back to the UI.
2. A consistent design pattern across all layers
3. Better exception handling
There also some drawbacks:
1. All calls to the DAL from the UI would now have to look like this:
AddLookupResponse response = Engine.APIProxy.AddLookup(SelectedLookupItem);
if (response.Result == Result.Success)
{
}
else
{
HandleResponse(response);
}
2. There is more code for each method, even though it allows all the handling to be done in the UI.
I welcome your comments.
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
IMHO, there are several issues with this design.
AddLookup() should execute within a transaction, since a LookupEntity could be inserted between the check and your insert.
- The case-insensitive string compare is flawed on several fronts: (1) A
.ToLower() compare will not work across all cultures. Instead use .ToUpperInvariant() . (2) Performing a case conversion is a performance bottleneck, since your code won't scale. Try running the compare on a million records containing large strings. Instead, perform a case-insensitive using string.Equals() with StringComparison.OrdinalIgnoreCase .
- The value of
_ResponseBase.Message depends on the order in which the instance's properties are set. This is a VBT. _ResponseBase should instead offer various constructors that set its different properties, all of which should have protected setters and public getters.
- Exceptions should be thrown, not returned. The only exception (pun intended) to this rule is when the thrown exception cannot be relayed across the network (e.g. ASP .NET MVC server exception to JS client layer).
/ravi
|
|
|
|
|
1. AddLookup() should execute within a transaction, since a LookupEntity could be inserted between the check and your insert.
I agree
2. The case-insensitive string compare is flawed on several fronts: (1) A .ToLower() compare will not work across all cultures. Instead use .ToUpperInvariant(). (2) Performing a case conversion is a performance bottleneck, since your code won't scale. Try running the compare on a million records containing large strings. Instead, perform a case-insensitive using string.Equals() with StringComparison.OrdinalIgnoreCase.
I agree
3. The value of _ResponseBase.Message depends on the order in which the instance's properties are set. This is a VBT. _ResponseBase should instead offer various constructors that set its different properties, all of which should have protected setters and public getters.
First, what's a VBT?
Second, I've never been a fan of having various constructors just to set properties. In my app, I always create a response first, then later in the method I set the properties I need. Then return the instance. Using CTOR's means having different "new MyReponse(property = value)" all over each method.
4. Exceptions should be thrown, not returned. The only exception (pun intended) to this rule is when the thrown exception cannot be relayed across the network (e.g. ASP .NET MVC server exception to JS client layer
This point is the real reason for my posting...
One problem I was having is when an exception occurred in the DAL/BL, the controller only returns "An exception has occurred". So I decided to create the responses to that I would always get something back.
Also, I've heard people say "Exceptions should be thrown, not returned", but I have yet to see a compelling reason why. The UI needs to know about the exception somehow. I just return it, then re-throw it in my HandleResponse to my exception handling routine can handle it. I means less code, a single place to handle exceptions, and a known format coming back in all cases.
Having said all this, I'm not really sold on this design, so feel free to rebut.
If it's not broken, fix it until it is
|
|
|
|
|
Kevin Marois wrote: what's a VBT? VBT == Very Bad Thing™
Kevin Marois wrote: I've never been a fan of having various constructors just to set properties. There are 2 benefits to initialization during construction: (1) Constructors allow dependency injection and therefore TDD. (2) Constructors guarantee a new instance can never exist in a malformed manner.
Your properties are badly designed (if you'll permit me this comment). The following pieces of code cause different results, which is a VBT.
_ResponseBase rb1 = new _ResponseBase();
rb1.Exception = new Exception ("foo");
rb1.Message = "bar";
_ResponseBase rb2 = new _ResponseBase();
rb2.Message = "bar";
rb2.Exception = new Exception ("foo");
/ravi
|
|
|
|
|
Ok, you're right. I see your point.
Aside from this, any other thoughts about my overall design? See any issues using responses?
If it's not broken, fix it until it is
|
|
|
|
|
I need to develop an application x32 on Windows 7 64-bit (MS Visual Studio 2010 and .net 2.0 - .net 3.5) that uses an x32 usb driver to connect an industrial equipement with 3 NI 32x dll references to run on a 32-bit Windows 7 ebedded pc.
I have tryed to develop a simple test application on my WinXP 32-bit laptop (it old, slow and has a small screen), and it works very fine on the Windows 7 embedded pc.
If I run my application with Platform 64-bit and targetting x64 and using x64 dll references it is also all ok with all the external equipements connected, but obviously I cannot run this application on the Windows 7 embedded 32x.
My question is: Is it possible to develop the whole aplication on Windows 7 64-bit that uses the 32x NI dll references and output an aplication to test on this machine and to upload and run on Windows 7 embedded 32-bit? Maybe using DPInst ...
Thanks to all!
|
|
|
|
|
Yes.
Open your project in VS, and double click the "Properties" branch in the Solution Explorer pane.
Select the "Build" tab on the left hand side, and change "Platform target" to "x86"
Rebuild your project - you may have to remove and re-add your references.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
I have tried many times, changing Platform target to "x32" doesn't work and Microsoft says: "You need to install 64-bit drivers for all your hardware devices to get the correct functioning in a 64-bit version of Windows. Drivers designed for Windows versions 32-bit will not work on computers running 64-bit versions of Windows. ".
|
|
|
|
|