|
Hi All,
I've been looking into AOP lately for a project and was wondering what the general consensus was in .NET land on this issue?
There are a few different approaches to this one can take, seems that the "pure" idea of AOP is performing compiler weaving with tools such as PoitSharp. However there isn't any budget for things like this so I started looking at LinFu which uses Cecil from the Mono project.
Having not implemented this before I'm interested in getting some info on real world experiences.
What kind of issues do we face in terms of debugging for instance? Also I wondering what the performance hits are like when using lots of proxies etc ...
Cheers,
Jammer
|
|
|
|
|
Hello everyone. First i want to say sorry for my possible mistakes expressing my self because my english is reduce. But i will try to make my self clear enough and misspellings.
Introduction: I'm using LINQ to make queries against database. I built a abstract BusinessBase class where i built the basic operations (CRUD)as generic methods and they will be inherited by others classes that may want to insert, Update,delete an entity or Get a collection with all entities, of a specific type, from a database. But, as iwant get an entity by its IDs, for all entities, i want to include the BusinessBase class the method that allow me to do that.
What i want to know is: there is any way to embed SQL syntax in a linq querie, becasue the properties that are keys are diferent in names and numbers from entity to entity. Something like that:
public TEntity GetEntityByIDs("Employees"(*),[("id1",value1),("id2",value2)]){
var query = from e in dbContext.GenericNameEntitiesCollection(**)
(using T-SQL)"WHERE id1(***) = value1(****) AND id2(***)=value2(****)"
select e
}
(*) the name of the property that gets the ObjectSet with the entities
(**) public ObjectSet<employee> Employees
(***) names of the fields table at the database
(****)the correspondent values at the database
|
|
|
|
|
Hello,
Im using vs2010 .NET 4.
Ive created a new WPF projects that uses assembley created in .NET 2.
When i tried to compile i got the next error:
"Mixed mode assembley is built against version v2.0.50727 of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information".
After googling i found the solution af adding those line to the app.config:
<startup useLegacyV2RuntimeActivationPolicy = "true">
<supportedRuntime version = "4.0" sku = ".NETFramework,Version
=v4.0"/>
/startup>
But the error still present. 
Can any one help?
Thanks.
modified 21-Nov-11 3:33am.
|
|
|
|
|
Add the following code, it should work properly
<startup uselegacyv2runtimeactivationpolicy="true"> <supportedruntime version="v4.0"> <requiredruntime version="v4.0.20506">
I have tried it.
|
|
|
|
|
What code?
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
|
|
Hi,
1.
there is no unboxing, and no run-time penalty, if one of your methods is declared as returning IEnumerable<string> and actually returns a List<string> or a string[]. The compiler has checked each return statement returns the promised type, and they do as both List and Array are implementing IEnumerable, so all interface members are available as is.
2.
AFAIK ToList() creates a new List. IMO most ToSomeThing() methods create a new object, the one exception I know of is the meaningless string.ToString()
|
|
|
|
|
Luc Pattyn wrote: is the meaningless string.ToString()
For being meaningless it sure is used quite often 
No comment
modified 21-Nov-11 21:00pm.
|
|
|
|
|
Mark Nischalke wrote: For being meaningless I sure it used quite often
It sure is.
|
|
|
|
|
|
when a method promises to return an IEnumerable, then it can actually return a List, an Array, a StringCollection, ..., as they each implement (hence ARE) IEnumerables. IEnumerables is just a more vague description of a pretty specific object which could be a List, an Array, etc. There is no conversion, no "new object" at all.
Collin Jasnoch wrote: why not just use List<T> or arrays for your return type?
I see at least two reasons why it could make sense:
1. you want to return something that the caller can perform only some operations on; when you return a List as an IEnumerable, the caller can enumerate the items in the list, and change those items, however he can't change the list itself. That is encapsulation.
2. assuming all that is required by the caller is IEnumerable, why offer him more? As a provider of the callee, you could change your implementation (say from arrays to lists), and still return the object as an IEnumerable, the caller wouldn't notice. And sometimes, you might return either an array or a List, using different return statements in your one implementation.
Example:
Since .NET 1.0 (when no generics existed) Directory.GetFiles has been defined as returning an array, which is expensive promise: while collecting the data, they don't know yet how many items will be present, so they must count first, allocate an array, stuff it, and then return it. Had it been declared returning an IEnumerable from day one, the current implementation could have taken full advantage of a generic list.
|
|
|
|
|
|
if you need a List, it is best for the method to return a List. Turning an IEnumerable into a list afterwards is expensive.
if all you need is an IEnumerable, then it does not matter one way or the other; there is no added cost in returning a List as an IEnumerable, just as there is no added cost in passing a TextBox to a method that expects a Control.
PS: and then there also is IList ...
|
|
|
|
|
|
You're welcome.
|
|
|
|
|
As i see it the only danger is that the client actually does not have to push anything back when you return List<t>. When he add's or removes something it it, by reference, also available/removed at the providers side. For safety reasons return the IEnumerable i'd say.
Cheers, AT
Cogito ergo sum
|
|
|
|
|
|
Your resoning seems sound if you're aiming towards a distributed system or at least have a proper seperation of UI and BL. If on the other hand the UI is just another part in the same process, which may or may not be another developer. In that case you will need to be a bit more careful.
Cheers, AT
Cogito ergo sum
|
|
|
|
|
Hi, all:
Does anyone know why the HasMorePages property seems to be ignored, or more correctly, is erratic an finicky.
Either the pages all print on one sheet or loop through pages-by-the-hundred (often each one a compound page).
Assuming the problem is my own understanding, I went to my own code (where I've used it successfully in the past), and checked with the MSDN site literature. This followed by various permutations as to where in the print routine it is called. At this point, I feel as a hamster on a treadmill.
- I've done the loop inside the PrintDocument_PrintPage(...) method.
- I've taken the print loop outside, wrapping the PrintDocument->Print() call (passing a 'done' flag to control HasMorePages).
Various permutations, some of which appear to ignore the code flow when followed in the debugger.
What I'm hoping for is either a description of how the methods and properties interact that is (mentally) consistent, or a link or two referencing such explanations.
As an axillary question, what would have been so difficult about creating a New-Page method instead of this looney-tune flag?
TECH NOTES: C++ in VS2003 (== .NET 1.1 because they won't upgrade).
Thanks, in advance.
Balboos
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
According to the documentation[^] you must set the ev.HasMorePages property inside the print page event handler. Does your code follow this model?
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Thanks for the reply. I deliberately didn't include the code snippets because I tried so many. Indeed, I've used it before - the event handler is the only place that ev.HasMorePages is in scope (as an arg), unless I pass it on (which, in desperation, I tried at one point). So - yes, it's in the right location.
Whilst awaiting feedback, I continue my online search and came up with what might be an explanation consistent with the observed problems:
e->HasMorePages results in another call to the printDocument handler. I can visualize this (apparently) erratic behavior as being the the result of this call. I'm going brain-dead, shortly, but know exactly what I plan to do in the AM, which can be summed up as declaring a static counter for my data loop, printing a single records worth of data to the form, and if more data is available, setting e->HasMorePages to true. Resetting the static counter only after the entire loops been handled.
Unintended recursion.
Again, though, thanks. It's good to ask about the obvious before one goes to the subtle.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I never had any problems with HasMorePages: when you call myPrintDocument.Print(), the system will fire a PrintPage event; your associated handler is where you must set PrintPageEventArgs.HasMorePages either true or false. As long as you don't set it false, the system will continue firing the PrintPage event. So you are not organizing the loop yourself, the system does it for you. You are responsible of course to provide the data that belongs to the page currently being printed, and normally the mechanism you need to achieve that is also what tells you whether more pages will be required or not.
FWIW: what I find more difficult to organize elegantly is the prediction of the number of pages the print job is going to require, this is the number you can provide to the PrintDialog in case you want to support partial page range printing. To get it right you either have to duplicate the paging logic, or somehow share it with the PrintPage handler itself.
|
|
|
|
|
Luc Pattyn wrote: As long as you don't set it false, the system will continue firing the PrintPage event
Thanks - this is the key: it's potentially recursive.
I'd just happened across a reference that said as much, which I posted. My plan is, as noted above, to use a static int as a counter (such as by giving it class scope), by which means it will (1) page and (2) not print everything on each page - or so I hope.
It's interesting that I've made this work for me in the past without understanding this simple but essential key to its use.
Thanks.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
You're welcome.
And yes, you need one or more variables that live outside the PrintPage handler, so they can remember how much your printing process already has handled.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
