|
visualst wrote: so, please help and teach me.
I think you should pick up a book on OOPS with .Net and read it.
Too much of heaven can bring you underground
Heaven can always turn around
Too much of heaven, our life is all hell bound
Heaven, the kill that makes no sound
|
|
|
|
|
hmm, i have a book. but i confuse in build a class like connection to databases.
but thank you for your advice.
|
|
|
|
|
|
how to get and display values in listbox in vb.net
|
|
|
|
|
One way to add values is to a add item by item.
E.g. listbox.Add("A");
You can add a range
E.g.
Dim s1 As String = "A"
Dim s2 As String = "B"
Dim s3 As String = "C"
listbox.Items.AddRange(New String() {s1, s2, s3})
A third way is to bind a collection to the listbox.
For this, you will use the DataSource and the DisplayMember property.
E.g.
listbox.DataSource = ds
listbox.DisplayMember = "ColumnName"
Too much of heaven can bring you underground
Heaven can always turn around
Too much of heaven, our life is all hell bound
Heaven, the kill that makes no sound
|
|
|
|
|
Further to the previous post, you can also iterate the listbox items collection like;
For Each item As String in listbox1.Items
Debug.Writeline(item)
Next
|
|
|
|
|
To expand on Dave's answer, remember that the items don't have to be strings (DataRows, for instance):
For Each item As String in listbox1.Items
Debug.Writeline(item)
Next
Could be
For Each item As DataRow in listbox1.Items
Next
Also, if you're looking for just the items that have been selected, replace
listbox1.Items with
listbox1.SelectedItems
|
|
|
|
|
Hi again,
i'm looking at transaction management for EF. MSDN docs says that transaction are enforced only in the data source level ....so there's no direct way to manage transaction directly at object level as for example in Java?
Thanks
Ste
Ste
|
|
|
|
|
Hi all,
I'm trying to understand where (and maybe if) there is a cache service for ADO.NET Entity framework.
I'm doing this just for a reasearch and comparison with JPA...
Java enforces two type of caches (one per entity context and one shared) but I do not find anything similar in .NET entity framework.
May anyone help me to deal with this problem?
Thanks
Ste
Ste
|
|
|
|
|
AFAIK there is no caching provided. It is up the developer to implement since EF can be used in a variety of situations and what works for one may not be appropriate or necessary in another.
No comment
|
|
|
|
|
So from this point of view (also academic point of view) Java Persistence API is better as is able to provide two different level cache where at least L1 cache does not provide any issues of concurrency, memory, and so on....
There're common widely used solution for 'manual' caching in ADO.NET EF can I check and mention?
I have just found this[^] on MSDN.
Thanks
Ste
Ste
|
|
|
|
|
You are trying to compare oranges and coconuts. They both may grow on tree but they are vastly different in many ways.
You can't compare a .NET technology to a Java technology and determine one is "better" than the other. They each have their purpose and usage.
No comment
|
|
|
|
|
I agree with you! but this is an academic assignment and I can't complain about this. Need to compare both appraches in term of: transparent mapping, caching, transactions, datastores, etc...
Ste
Ste
|
|
|
|
|
Yes, then academically you can't conclude one is "better" than another. Present the facts.
Good luck
No comment
|
|
|
|
|
There is no "this is better than that" in your comparison. There is "what would be more appropriate for this situation". The answer you're trying to get is for all situations, and that isn't a valid conclusion.
There will be situations where Javas Framework would be more appropriate and situations where EF would be more appropriate. Present your facts based as to the strengths and weaknesses of both frameworks.
For example, you seem to think that the Java framework is better because it supplies caching in a couple of contexts whereas EF doesn't supply any. But, did you look into the limitations of Javas caching mechanisms?? Are you design and/or performance bounded by these limitations?? Can you provide custom caching solution? The EF allows for custom caching solutions to be implemented, so does that make it better than Javas?
Is the metric, based on caching alone, going to be the performance benefits of the out-of-the-box caching capabilities or is it going to be the work required to implement a custom caching scheme??
I could keep going, but part of your paper is going to have to explain your testing methodologies and metrics, so it's entirely up to you.
|
|
|
|
|
Perfectly agree with you even if I think that is still complicated to manage this kind of compare and contrast
Ste
Ste
|
|
|
|
|
Hi, I've found reading an academic paper about Anatomy of the ADO.NET EF[^] that there's a cache provider available in the Object Services...
Ste
Ste
|
|
|
|
|
Yes, this is for internal use to maintain state information about the objects necessary for comparision in determining changes. It isn't a data cache that can be used for storing query results and can be disabled by setting MergeOption.NoTracking.
No comment
|
|
|
|
|
Hi all,
I'm trying to understanda which are the major pros and cons of ADO.NET entity framework compared to the JPA (java persistence API).
Looking and comparing manual is not easy as I'm not a developer (neither java nor .NET) so any help and feedback is appreciated.
I've google out of course for this question but there're not interesting docs or blogs related to this and of course it's difficult to find someone know both language. So any hints is appreciated.
Thanks
Ste
|
|
|
|
|
There's no 1-1 comparison, just like there's no comparison between the seats of a Porsche and a Jaguar. Both are seats for their specific cars and both do their job well in their own environment.
Usually we look at the language that our devs' are most familiar with, and go with the frameworks that come with that particular language. The choice between Java/.NET is more based on resources, like your devs, and the environment it's going to work under.
Bastard Programmer from Hell 
|
|
|
|
|
Yep I know. I'm doing this kind of compare as an academic work focussing my attention to some specific topic as: transparent mapping, encapsulated persistence, multi object retrieval, caching, transactions, data sources...
Now I've found that (for .NET EF):
- it does not provide any cache feature by defaults
- transparent mapping is more complicated than jpa
- if u load an object linked with FK to others, all dependents object are loaded and there's no way to limit this
- transactions are enforce inside datasource layer...but have to find other infos
Any hints is appreciated. I can state that there're definitely more infos on JPA than .NET and also MSDN is not so clear ...
Ste
Ste
|
|
|
|
|
oraclepilot wrote: <layer>Any hints is appreciated. I can state that there're definitely more infos on JPA than .NET and also MSDN is not so clear ...
MSDN is aiming at developers; it's easy to find syntax, how-to's and even video's. You probably already found the portal[^] that links to the EF-forum. The overview[^]-page contains links to most of the stuff on MSDN relating the EF.
There's very little in terms of feature-lists. You'll find more on Wikipedia[^], like the ormeter[^].
oraclepilot wrote: I'm doing this kind of compare as an academic work
Good luck 
Bastard Programmer from Hell
|
|
|
|
|
oraclepilot wrote: I'm trying to understanda which are the major pros and cons of ADO.NET entity
framework compared to the JPA (java persistence API).
I don't see that that is a reasonable comparison.
Some reasons why...
- You can't arbitrarily pick one or the other without consideration for what it will be used in (not features but technology.)
- JPA by itself is a specification, not an implementation.
|
|
|
|
|
Interesting...I've never thought in this way.
To be specific, I have to compare the approach to persistence of objects between JPA and ADO.NET (not specifically ADO.NET EF) but AFAIK ADO.NET permits to persists object with LINQ to Entities and today with EF...right?
Ste
Ste
|
|
|
|
|
I don't understand the question.
In this situation the requirements/architecture/design is going to have far more impact on any attribute in terms of comparison. That true for applications in general but it specifically true of database APIs.
And that has nothing to do with your implementation choice.
But your implementation choice is going to have a big impact on the entire application and even potentially the company as well. For example it would seem foolhardy for a business that has experienced C# developers to commit to a java platform even with some small gain.
To truly demonstrate a real benefit (something measurable that is a real attribute of the API) then all of the following must be true.
1. Such a need must exist in the first place. So for example if you must need to actually push 10,000 txns a second and you CAN'T use any other solutions (such as direct data load.)
2. One must be very experienced in ADO.Net.
3. One must be very experienced with a Java library that implements JPA.
If 2 and 3 are not both true then one runs the risk of measuring ignorance rather than API.
If 1 isn't true then other factors, like what language the company normally uses and how the API will be used are much more significant.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
