|
Thank you, F-ES Sitecore. I even used EF in my project but one interesting thing is in Chinese developing community many developers don't advise me to use EF because they believe EF isn't stable. Thank you for your adivces and I will look into EF seriously!!!
|
|
|
|
|
There's nothing wrong with using EF. It won't be as fast as things like ado.net that you're currently using, but you have to weigh that up against development time and simplicity. It's not slow, just slower than ado.net and for most people the performance is still fine. You do have to keep an eye on things like lazy loading as how you use EF can affect the performance of it, but you'll find all that out if you look into it.
|
|
|
|
|
Thank you again and again! You give me another view looking at EF. Thank you again!!!
|
|
|
|
|
You might want to take a look at Dapper[^], which is used on the StackExchange family of sites. Since your SQL column names seem to match the property names on your UserModel class, it should be fairly simple to use:
private IDbConnection CreateConnection()
{
return new SqlConnection("YOUR CONNECTION STRING HERE");
}
public IEnumerable<UserModel> SelectAllUser()
{
const string sql = @"SELECT [UserID], [Password], [Name], [Sex], [Phone],"
+ "[Tutor], [DptName], [College], [University],"
+ "[Major], [EnrollYear], [Cntnt] "
+ "FROM [TrainingExam].[dbo].[ExprmntUser]";
using (var connection = CreateConnection())
{
return connection.Query<UserModel>(sql);
}
}
public int InsertUser(UserModel user)
{
const string sql = @"INSERT INTO [TrainingExam].[dbo].[ExprmntUser] VALUES ("
+ "@UserID, @Pass, @Name, @Sex, @Phone, @Tutor, @DptName, @College, @University, @Major, @EnrollYear, @Content)";
using (var connection = CreateConnection())
{
return connection.Execute(sql, user);
}
}
public int DeleteUser(UserModel user)
{
const string sql = @"DELETE FROM [TrainingExam].[dbo].[ExprmntUser] WHERE UserID = @UserID";
using (var connection = CreateConnection())
{
return connection.Execute(sql, user);
}
}
public int UpdateUser(UserModel user)
{
const string sql = @"UPDATE [TrainingExam].[dbo].[ExprmntUser] SET UserID = @UserID, Name = @Name, Sex = @Sex, Phone = @Phone, EnrollYear = @EnrollYear, "
+ "Tutor = @Tutor, Major = @Major, DptName = @DptName, College = @College, University = @University, Content = @Content "
+ "WHERE UserID = @UserID";
using (var connection = CreateConnection())
{
return connection.Execute(sql, user);
}
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Wow, it is really cool!!! Dapper can use my code smoothly!!! Thank you very much!!!
|
|
|
|
|
Hi, Richar! I can't visit Dapper. It seems that Github is blocked. Could you give me independent Dapper site ???
|
|
|
|
|
You can install the package from NuGet:
https://www.nuget.org/packages/Dapper/[^]
However, all of the documentation is on GitHub, which seems to be blocked in China.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thank you, Richard. I have download Dapper with Nuget Package Manager. I learn Dapper right now!
|
|
|
|
|
Hey,
I would like to discuss the value of using Unsigned value types for ensure the validy of your buissnes logic.
Just to name some exampels.
Does it make sense to let the Linq Extention 'Skip' or 'Take' be, accepting values smaller then 0? No not for me, but then why it allows this behavior by taking a int instead of an uint? Don't mention that the uint takes less memory but this is not the point.
I meant that the same space in memory can hold a bigger number ( for int ) then the signed as we got a bit more to store our data. ( sory for the vague explanation )
I Developed a network lib ( currently not OpenSource but soon ) that takes a Port. i saw that other libs are using an int at this point. This is absolute bad from my point of view. The only valid value type here is the Ushort ( 0 to 65,535 ). It does not allow a non Positiv number and limits the parameter to the buissnes logic. So why are thees value types not used that often?
modified 27-Mar-15 5:35am.
|
|
|
|
|
|
|
Jean-Pierre Bachmann wrote: Don't mention that the uint takes less memory
Um. No, it doesn't.
A uint occupies the same amount of memory as a signed int - 32 bits, or 4 bytes - and takes the same number of different values.
The difference is that it's range of values is different:
int: -2147483648 to 2147483647
uint: 0 to 4294967295
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
1) I agree (too)
2) Unsigned types are not "CLS compliant" - I guess that's the main reason. See here[^] and here[^].
|
|
|
|
|
Because it is annoying to mix int and uint. Unlike in, say, C++, you get casts everywhere. short/ushort is even more annoying. Also even if you did use them, they wouldn't really work the way you'd like them to work (ensuring the input is valid I guess), they'd just be wrong differently. If you cast an int that is accidentally -1 to an uint and give it to Take it will still be a bug. If you cast 10000000 to an ushort and pretend it's a port, it'll be a valid port but it won't be the right port. And so on.
|
|
|
|
|
Jea but this is the point, i am forced to cast my number to an ushort, and if its not possible the fault is on "your" side. I are not even able to cast your 10000000 to ushort because its not possible for that way i enforce you to validate by your self and im force you to thing about your code that that's is obviously a good thing or not? Same as Take.
ushort test;
int test2 = 10000000;
test = (ushort)test2;
will compile but cause an error at Runtime. But in your code. in that way i protect my pice of code and enforce you to do the same on your side.
|
|
|
|
|
Runs fine for me. I just get 38528.
|
|
|
|
|
Jean-Pierre Bachmann wrote: Don't mention that the uint takes less memory but this is not the point.
uint does not take less memory than a int, they have the same exact size - it changes only the representation from pure binary to 2's complement.
Integers are the basic echange unit in the system, they allow checking for overflows and underflows: if you use a ushort in a port number and have something bad that wraps around you won't get a negative number but a perfectly valid port number. If you'd have something that overflows you would still get a perfectly valid port number.
Unless you have to store/send 2 bytes values in some form of structure or have to make bit operations on 16bit wide operands there is no real need of shorts - and if you don't have to convert decimal values in 16 bits values you won't need unsigned versions of it either since math operations yields off the same binary signature. Even if you should read a decimal value and convert it in a 0-65535 range it would be better to use an int as a middle step because there may be the possibility of reading a greater number.
These are my reasons, stemmed from my experience of course.
Geek code v 3.12
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
I use 1TBS
|
|
|
|
|
Jean-Pierre Bachmann wrote: This is absolute bad from my point of view. .... So why are thees value types not used that often?
Because people are more concerned, rightfully so, in making sure that the functional logic of the software is correct versus trivial considerations.
In general it is probably 'easier' to use an integer. And your library should probably expose it as such and you should add the one statement in your code where it is exposed to do a validation check. And then move on to make sure that the rest of your library works as promised.
|
|
|
|
|
I have bound a BindingList<Produkt> to a ComboBox. When the user writes some text into the combobox, it will remove (filter out) all the entries that doesnt match what the user has entered, and then open the list showing the rest for the user to select one. The idea is that the more the user writes, the fewer options will be listed. The binding and filtering part works fine, but the problem is that when the user writes the first letter, the list opens up and autocompletes (in the text field) with the first entry of the list. Is there a way to turn this auto-completion off? I want the user to have the opportunity to keep writing OR to actively select an entry from the list.
public void Init(BindingList<Produkt> _produktLst)
{
produktLst = _produktLst;
namnCbx.DataSource = produktLst;
namnCbx.DisplayMember = "Namn";
namnCbx.ValueMember = "Namn";
}
private void namnCbx_TextChanged(object sender, EventArgs e)
{
RunFilter();
}
private void RunFilter()
{
BindingList<Produkt> filteredLst;
if (namnCbx.Text.Length == 0)
{
namnCbx.DataSource = produktLst;
}
else
{
filteredLst = new BindingList<Produkt>(produktLst.Where(delegate(Produkt p)
{
if (!p.Namn.Contains(namnCbx.Text))
return false;
else
return true;
}
).ToList());
namnCbx.DataSource = filteredLst;
if(namnCbx.Focused)
namnCbx.DroppedDown = true;
}
}
}
|
|
|
|
|
I think this question might boil down to: Can you open the list of a combobox without having one of the list entries selected, ie having something entirely different in the input field?
|
|
|
|
|
Have you thought about using the AutoComplete property on the combobox and set it to suggest?
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
Well, my idea was to not use any autocomplete, but I found this article Auto Complete ComboBox[^] where he is using it, and it works really well, just a slightly different approach. So five starts on that one.
|
|
|
|
|
Hello I am doing a project in c# and need to send pdf in email body rather than as attachment. ?? Please hemp me with some sample code. thanks
|
|
|
|
|
It doesn't quite work like that.
We do not do your work for you.
If you want someone to write your code, you have to pay - I suggest you go to Freelancer.com and ask there.
But be aware: you get what you pay for. Pay peanuts, get monkeys.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
The PDF has to be an attachment. PDF's don't render in an email body.
|
|
|
|