כמו שארכיטקט אמר - תוכל להגדיר את הערך ההתחלתי גדול במיוחד ואז תהיה בטוח בקידומת (בהנחה שגידול השורות לא רציני).
פורסם במקור בפורום CODE613 ב21/05/2014 11:13 (+03:00)
כמו שארכיטקט אמר - תוכל להגדיר את הערך ההתחלתי גדול במיוחד ואז תהיה בטוח בקידומת (בהנחה שגידול השורות לא רציני).
פורסם במקור בפורום CODE613 ב21/05/2014 11:13 (+03:00)
הנושא הזה נקרא DataBase Migration.
אני גם סבור כמו ארכיטקט שבמקרים פשוטים הכי קל זה לעשות לבד.
יש כל מיני כלים לכך, אבל השימוש בהם לא נראה לי פשוט. חפש בגוגל C# DB Auto migration.
אגב, בCodeFirst הבעיה הרבה יותר רצינית, כי זה מיועד בשביל כאלה שלא רוצים בכלל ליגוע במסד, ובאמת בגירסאות האחרונות יש כלי לזה, אני לא התנסיתי בו.
פורסם במקור בפורום CODE613 ב21/05/2014 11:12 (+03:00)
תודה רבה רבה!
נשמח לעדכונים וטיפים בנושא.
פורסם במקור בפורום CODE613 ב20/05/2014 13:32 (+03:00)
נו, מתגברים...
http://stackoverflow.com/a/11404731/1271037
http://stackoverflow.com/a/12652259/1271037
פורסם במקור בפורום CODE613 ב29/05/2014 16:18 (+03:00)
אי תלות בגורמים חיצוניים זה אלף בית של לכידות תוכנה, ומה שקשור להכנסת נתונים לדטה בייס, אילוצים, בדיקות, צריך להתבצע בדטה בייס.
אתה מדבר מהבחינה העקרונית, ואני מדבר על האמצעי הפרקטי ששמו טריגרים, שהוא אמצעי עם שימושיות נמוכה ב'שטח'.
יש עניין לעשות כמה שיותר עם הטריגרים וכו' בחברות הגדולות זו העבודה של הDBA.
זהו, שיש לי תחושה שונה לגמרי לגבי ה"טריגרים" (לאפוקי ה"וכו'") כשבאתי במגע כל שהוא עם DBA ברשת.
פורסם במקור בפורום CODE613 ב19/05/2014 15:33 (+03:00)
אני לא קונה את האילוץ שלך לעשות הכל ברמת הDB.
כל הקטע של הטריגרים, נדמה לי שהוא אמור להיות משהו שולי בDB, לא משהו שהמערכת נשענת עליו כמו המשקל ששמת עליהם.
אולי אני טועה, אבל ככה נראה לי.
פורסם במקור בפורום CODE613 ב19/05/2014 13:12 (+03:00)
הליסט שעשית היא מקור נתונים, ואנו מדברים על התנהגות של הפקד הויזואלי.
ללא קשר למה ואיך מקור הנתונים.
אכן טעיתי ובדוקמנטציה מופיע שזה משפיע גם על לחיצת מקש.
מופיע שם גם שכאשר מגדירים את המאפיין לחיובי יש להגדיר את הSelectionmode כשלילי.
בקשר להתנהגות גם במקרה שלא עשית שום מאפיין מסויים רק שמקור הנתונים זה ליסט אישית, נסה לעשות דמו קטן ולהעלות קוד + XAML רלוונטי.
פורסם במקור בפורום CODE613 ב19/05/2014 15:40 (+03:00)
מה זה נקרא שעשית ליסט לבד? טמפלט? כתבת בעצמך את מחלקה יורשת מListView?
העובדה שרווח בוחר ממש לא קשורה. אין סיבה שהוא לא יבחר כל עוד הSelectionMode לא מוגד כNone. המאפיין מדבר רק על קליק עכבר.
בנוסף תרחיב מה אתה רוצה (כלומר, שורה תחתונה) כך שאבין אותך יותר.
פורסם במקור בפורום CODE613 ב19/05/2014 14:18 (+03:00)
פשוט מאוד, כשאתה לוחץ על אייטם, בברירת מחדל מופעלת לוגיקה של הפקד לבחור את האייטם.
המאפיין הנ"ל אומר: "אל תבחר. תלחץ! תעורר אירוע לחיצה וזהו. אני כבר אסתדר עם הבחירה".
פורסם במקור בפורום CODE613 ב19/05/2014 13:21 (+03:00)
הרעיון היחיד שאני שומע כאן זה להשתמש בתוכנה נפרדת לשליחה, והיא עצמה תפעל ללא טרידים כלל (קצת חבל כי זה ייקח לה הרבה זמן).
לא כ"כ הבנתי את הנקודה של המופעים.
הנקודה האם התוכנה תהיה סרביס או תוכנה רגילה בלתי נראית, היא חסרת משמעות לענייננו.
סרביס, זה "של וינדוס" בדיוק כמו כל תוכנה אחרת שלך. ההבדל בין סרביס לתוכנה רגילה זה סה"כ העדר משתמש גרפי וריצה פר מכונה ולא פר USER. יש עוד פיצרים כמו אתחול מחדש בכישלון וכו' וזה באמת רלוונטי למקרה שלך קצת, אבל זה לא מוריד ממך שום דאגה מהסוג שהעלית פה באשכול.
פורסם במקור בפורום CODE613 ב15/05/2014 17:30 (+03:00)
בעיית התאריך והשעה מצריכה אותך לדאוג שיהיה במסד אינדקס מוצלח לכך (לדעתי אינדקס על התאריך שעה מפולטר כלומר עם where שלא נשלח, אבל ייתכן שיותר זול אינדקס שמורכב משתי העמודות. בכל מקרה שהאינדקס "יכסה" את כל העמודות הנדרשות לתשובה) ואז המהירות תהיה דומה.
ההבדל בין paralel לtask שהצעתי זה בגלל שרציתי ל"שגר ולשכוח" ואילו Paralel עושה במקביל אבל ממשיכה רק אחרי שכולם גמרו.
פונקציית הטעינה נגמרת מייד ע"י סיום יצירת הTask פר שורה (מיידית). הTask ממתינים לריצה עד שהפונקציה תיגמר ואז הם מתחילים כולם בו זמנית - אבל בצורה מבוקרת - אחרי XXX שהתחילו המנהל חוסם את היתר, עד שאחד יפנה מקומו וכו'.
לא חשבתי שאתה מכיר לעומק את הבו זמניות בדוט נט, אבל ביקשת שניתן לך כיוון. בשביל ללמוד את הTask תתחיל להשתמש בזה בפרוייקט קטן, ותדמה מהירות נמוכה ע"י Sleep.
פורסם במקור בפורום CODE613 ב15/05/2014 15:41 (+03:00)
זה מאוד מאתגר הנושא.
אני לא בטוח הבנתי הכל:
אז אני מדמיין מחלקה כזאת:
שדה מספרי (להלן LastId), מייצג את מזהה הרשומה האחרונה שנכנסה.
מנהל Task - משהו שנקרא TaskScheduler. אפשר ליצור ממנו כמו טרידים עם שליטה על המספר הבו זמני של הביצוע.
פונקציית טעינה: שאילתה מהDB לשורות אשר לא נשלחו והID שלהם גדול מLastId - יצירה פר שורה של Task ע"י המנהל.
טיימר לפונקציית הטעינה אפי' כל דקה.
המושג Task הוא טריד ידידותי מאוד למפתחים. הוא מכיל בו הוראות מה לעשות בעת פעולה והוראת ריצה אסינכרונית (בברירת מחדל). כל עוד הוא לא מורץ הוא רק תופס את הזיכון של מס' שדותיו, וזה כמו מחלקה רגילה. אם הסקבילריות דורשת לדמיין שיהיו מליון רשומות שנטענות בו זמנית (ונקודת זמן אחת), אז יש מקום למנוע טעינת כל השורות ישירות לTask אלא לעשות תור FIFO - בדוט נט זה: Queue<T> ובסיום מאה Task לדוגמה, לטעון חזרה חדשים עד סיום התור.
פורסם במקור בפורום CODE613 ב15/05/2014 15:05 (+03:00)
שלא כמו בSqLite או Comact Sql ואקסס, שם התוכנה ניידת לגמרי כי היא/הפימוורק כוללים את מנוע המסד,
LoaclDb זה מסד של ממש, אחיו הקטן של SQL SERVER EXPERSS, והוא מחייב התקנה (אם כי קטנה וקלה לאין ערוך ביחס לאחיו הגדול).
ההתקנה נמצאת כאן: http://www.microsoft.com/en-us/download/details.aspx?id=29062
הקובץ הנצרך זה ENU\x86\SqlLocaLDB.MSI ל32 ביט, או ENU\x64\SqlLocaLDB.MSI ל64 ביט.
פורסם במקור בפורום CODE613 ב15/05/2014 16:51 (+03:00)
כשמוחקים את כל השורות במקום לעשות שאילתת מחיקה יותר מהר לעשות Truncate table XXX.
פורסם במקור בפורום CODE613 ב15/05/2014 18:46 (+03:00)
שים לב שלמיילים אתה יכול לעשות עמודה מסוג varchar ולא nvarchar מכיון שממילא התוים שאין בראשון הם לא חוקיים במייל.
אפרופו אימות מיילים, הצרה היא שגם מיילים לא חוקיים יכולים להיות קיימים ועובדים, בהתאם לספק מדינה ועוד.
יעויין פה:
http://stackoverflow.com/a/201378/1271037
ובקישורים של ההודעה, וגם פה: http://www.regular-expressions.info/email.html
מהקישור האחרון של Stackoverflow גיליתי משהו חדש - אתר לregex שנראה מעניין: https://www.debuggex.com (הרשמה קלה באמצעות חשבון gmail פעיל ודומיו) יש לו מציג ביטויים ויזואלי ועוד דברים.
פורסם במקור בפורום CODE613 ב15/05/2014 12:14 (+03:00)
אפשר יותר, כעת ראיתי פה במסמך צריך להעמיק בו http://www.moc.gov.il/sip_storage/FILES/7/167.pdf
פורסם במקור בפורום CODE613 ב14/05/2014 15:25 (+03:00)
תוכל להתנות את הקידומת באורך - כלומר שאם הספרה השניה זה 5, מוכרח שיהיו 10 ספרות (בתנאי שהספרה הראשונה היא אפס, אחרת זה יכוול להיות טלפונים מסוג 1500...).
תראה פה את כל האפשרויות: קידומת טלפון בישראל
פורסם במקור בפורום CODE613 ב14/05/2014 14:59 (+03:00)
ברור שאפשר.
אני מאמין גם שלך יצא כבר הרבה לגשת לResource (אין הבדל בין רמת החלון לרמת האפליקציה) ראה בסוף תשובתי כיצד.
אבל אתה צריך לגשת לתת אלמנט של אלמנט חי, ולא למפלט שהיא התבנית לייצרו.
אתה צריך לעשות ככה:
Window yourElement = this; //לא נראה לי שמדובר בחלון, אבל ככה אמרת
Border yourBorder = (Border)yourElement.Template.FindName("aBorderNameOfTemplate", yourElement);
yourBorder.IsEnabled = false;
בשורה הראשונה אני לוקח את האובייקט הקיים שרק בו אני רוצה לעשות שינוי באחד מאלמנטיו שנוצרו אוטומטית ע"י הטמפלט.
ע"י המתודה FindName של הטמפלט של אותו אובייקט אני מחפש את האלמנט Border לפי שמו שנתת לו (אם לא נתת, תן) בטמפלט.
בשולי התשובה, לשאלה איך ניגשים לResource (כל מה שנמצא בXAML תחת האלמנט Resource של כל סוג אלמנט, החל בכפתור, חלון או אפליקציה - App.Xaml):
רמת חלון:
Style yourStyle = Application.Current.Resources as Style["keyName"];
רמת אפליקציה:
Style yourStyle = this.Resources as Style["keyName"];
במידה ואין לStyle שלנו Key כי הוא גלובלי, הקומפיילר למעשה כן נותן לו Key - הטיפוס עצמו. לדוגמה סטייל שהTargetType שלו הוא Button, ניגש אליו ככה:
Style yourStyle = Application.Current.Resources[typeof(Button)] as Style;
פורסם במקור בפורום CODE613 ב14/05/2014 11:18 (+03:00)
כעת אני חושב, שלו נרצה לשתף את הפונקציונליות של ההגנה על יצירת חדשים, היה עלינו לגזור את מדינה עיר ורחוב ממחלקת בסיס עם ה"פטנט" הזה (רשימה פנימית סטטית ומחלקה שמחזירה איבר קיים או יוצרת חדש).
אך הבעיה שהן הרשימה והן המתודה חייבים להיות סטטיים, וזה אומר שלא זו בלבד שאין ירושה אלא גם מדובר באותה הרשימה (למדינות והערים והרחובות) למעשה אני לא מצאתי בראש דרך לירושה כזו.
פורסם במקור בפורום CODE613 ב13/05/2014 16:18 (+03:00)
ההיררכיה שציירת היא היררכיית מופעים, לא מחלקות. ייתכן שיש בחלה גם היררכיית מחלקות, אבל בא נניח שאין.
במקרה כזה אתה צריך לעבוד כמו שהעלית את האפשרות עם מאפיינים המצביעים על האב/ילדים/אחים.
הנה דוגמה בסיסית:
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
var israel = new State();
var Jerusalem = new City (israel);
var Yafo = new Street(Jerusalem);
var MyHome = new Home(Yafo);
Console.WriteLine("My Home is: {0}", MyHome);
Console.WriteLine("My Street is: {0}", MyHome.Street );
Console.WriteLine("My City is: {0}", MyHome.Street.City );
Console.WriteLine("My State is: {0}", MyHome.Street.City.State);
}
}
class State { }
class City
{
public State State { get; set; }
public City(State state)
{
State = state;
}
}
class Street
{
public City City { get; set; }
public Street(City city)
{
City = city;
}
}
class Home
{
public Street Street { get; set; }
public Home(Street street)
{
Street = street;
}
}
}
בשביל לשלוט על אוספי המדינות וכו' כמו שאמרת למנוע יצירת כפולים וכדומה הרעיון של סינגלטון דומה למה שצריך לעשות. צריך לעשות אוסף פנימי של כל המדינות, ויצירה של מדינה חדשה היא רק ע"י פונקציה סטטית שחברה במחלקת המדינות. הנה הצעת הגשה:
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
var state = State.GetState("israel");
...
}
}
class State
{
private State() {} //בנאי פרטי מונע יצירת חדשים בדומה לסינגלטון
//אוסף פנימי מסוג המופע עצמו - אוסף מדינות
static Dictionary<string, State> StateCollection = new Dictionary<string, State>();
//פונקציה ציבורית לקבלת מדינה (קיימת או לא)
public static State GetState(string name)
{
State result;
if(StateCollection.TryGetValue(name, out result) == false)
{
result = new State(); //מתוקף היות הפונקציה בתוך המחלקה היא רשאית לבנות חדש
StateCollection.Add(name, result);
}
return result;
}
}
}
כמובן שבמקרה אמיתי נכלול במדינה מאפיין עבור שמה ("Israel") ולא נסתמך על הKEY שמחזיק אותה (או שם המשתנה כמו בדוגמאות שלי...).
היררכיית ירושה לא משקפת כלל את הקשר בין המופעים, אלא את הדימיון/נגזרות בין הג'ובים של כל חלק (מחלקה) בתוכנה. מאוד ייתכן (ממש לא מוכרח) שתהיה כאן איזושהי היררכיית ירושה, אבל ממש בלי קשר להיררכיית המופעים. כלומר ייתכן שדוקא מדינה תירש מרחוב - הכל לפי המאפיינים והמתודות האופייניים למחלקות אלו. זה בעצם היררכיית זמן עיצוב. נניח בדוגמה האחרונה גם לרחוב יפו וגם לבית שם יש אותה מדינה בזמן ריצה, אבל אין להם משותף כלל מבחינת זמן העיצוב. הדמיון שכן אפשר למצוא ביניהם, זה למשל שלשתיהם יש מאפיין של מיקום במפה.
אם רוצים שלכל ההיררכיה יהיו מאפיינים ישירים לסבותיהם (אולי זה מה שהתכוונת, סליחה שלקח לי זמן להבין), אז יש כאן מקום להיררכיית זמן עיצוב: גם למחלקת רחוב וגם למחלקת בית יש מאפיין בשם מדינה. אפשר לחסוך את החזרה על הלוגיקה של הצהרת המאפיין ואתחולו גם ברחוב וגם בבית. משהו כזה:
class City
{
public State State { get; set; }
public City(State state)
{
State = state;
}
}
class Street : City
{
public City City { get; set; }
public Street(City city) : base (city.State )
{
City = city;
}
}
class Home : Street
{
public Street Street { get; set; }
public Home(Street street) : base (street.City)
{
Street = street;
}
}
ואז כשיש לנו ביד בית, ואנו רוצים לדעת את מדינתו, במקום לכתוב כמו למעלה ככה:
Console.WriteLine("My State is: {0}", MyHome.Street.City.State);
נוכל לכתוב ישירות:
Console.WriteLine("My State is: {0}", MyHome.State);
על אף שלא כתבנו מאפיין State במחלקת Home, וזה אודות לירושה.
סליחה על הדרשה, ובהצלחה!
פורסם במקור בפורום CODE613 ב13/05/2014 15:26 (+03:00)