תחומים - פורום חרדי מקצועי

קודם כל אתה מסנן רשימות ולא דטהבייס ויש הבדל גדול
לסינון מול דטהבייס יש כלים שיודעים לבנות לך שאילתה מכל הבלגאן הזה

ANYWAY מה שכתבת הוא קוד ספגטי קלאסי - דע לעתיד שאם קוד מגיע לכזו רמת סיבוכיות אז משהו בגישה שלך לא נכון (אקסס - יוצא מן הכלל)

לסינון רשימות אפשר לעשות סינון חוזר של אותה רשימה משהו כזה:

static void Main(string[] args)
{
    List<Donor> dnrSource = new List<Donor>();

    dnrSource.Add(new Donor { FirstName = "John", LastName = "Doe", Address = "31 Peachtree st."});
    dnrSource.Add(new Donor { FirstName = "Jane", LastName = "Doe", Address = "31 Peachtree st." });
    dnrSource.Add(new Donor { FirstName = "Jane", LastName = "Doe" });

    List<Donor> dnrFiltered = new List<Donor>(dnrSource.ToArray());
    
    if (!string.IsNullOrEmpty(FirstNameSearch.Text))
    {
        dnrFiltered = new List<Donor>(SearchString(dnrFiltered, "FirstName", FirstNameSearch.Text));
    }

    if (!string.IsNullOrEmpty(LastNamesearch.Text))
    {
        dnrFiltered = new List<Donor>(SearchString(dnrFiltered, "LastName", LastNamesearch.Text));
    }

    if (!string.IsNullOrEmpty(Addresssearch.Text))
    {
        dnrFiltered = new List<Donor>(SearchString(dnrFiltered, "Address", Addresssearch.Text));
    }

}

פורסם במקור בפורום CODE613 ב09/08/2015 20:17 (+03:00)

עשית קצת מישמש

מחלקה אבסטרקטית זה מחלקה שמיועדת לתאר קווים מנחים (ובדוטנט גם פונקציונליות) משותפים לאובייקטים שיירשו ממנה - קרי - מיועדת על מנת שיירשו ממנה ויממשו את המתודות במחלקה היורשת, היטיבו לתאר זאת בשפת VB שם מחלקה אבסטרקטית נקראת MustInherit . . .

אתה למעשה צריך כאן מחלקה סטטית, מחלקה סטטית היא מחלקה שאי אפשר ליצור ממנה אובייקטים והיא למעשה סוג של מחסן קוד, מה שאתה צריך כאן.

פורסם במקור בפורום CODE613 ב09/08/2015 16:20 (+03:00)

אין לי זמן לעבור על הכל, אך מלמעלה:
קודם כל לא ברורה לי הבחירה ב abstract class
פונקציה כללית לחיפוש יכולה להיראות כך:
public static IEnumerable<T> SearchString<T>(IEnumerable<T> lst, string sProperty, string sVal)
{

    MemberInfo mi = ((MemberInfo)typeof(T).GetField(sProperty) ?? (MemberInfo)typeof(T).GetProperty(sProperty));

    if (mi == null) throw new ArgumentException("Field/Property does not exists", "sProperty");
    
    if (mi.MemberType == MemberTypes.Property) 
    {
        return lst.Where(d => (((PropertyInfo)mi).GetValue(d) ?? "").ToString().Contains(sVal));
    }
    else
    {
        return lst.Where(d => (((FieldInfo)mi).GetValue(d) ?? "").ToString().Contains(sVal));
    }
}

פורסם במקור בפורום CODE613 ב09/08/2015 13:36 (+03:00)

בעזרת האופרטור ?? (null-coalescing)

foreach (Donor donor in AddTorem.donors)
            {
               if ((donor.Email ?? "").Contains(email))
                result.Add(donor);   
            }

פורסם במקור בפורום CODE613 ב09/08/2015 13:45 (+03:00)

והנה פשוט יותר עם linq

public static IEnumerable<Donor> SearchName(IEnumerable<Donor> lst, string sName)
{
     return lst.Where(d => d.FirstName == sName || d.LastName == sName);
}

פורסם במקור בפורום CODE613 ב09/08/2015 11:09 (+03:00)

יש משהו שאני פעם כתבתי ל winforms, לא יודע אם יש משהו אחר...
JS לא רלוונטי לך

פורסם במקור בפורום CODE613 ב06/08/2015 13:59 (+03:00)

@אהרן

א. <use strict>? אתה מכניס א"ז בקביעות לסקריפטים שלך?

כן.
@אהרן

ב. מה??

תחשוב על with כמו import שעושים ב C# למרחב שמות לדוגמה אם תרשום ב JS ככה:

var r = 10;
with (Math) {
  x = r * cos(PI);
}

זה זהה ל:

var r = 10;
var x = r * Math.cos(Math.PI);
console.log(x);

זה פשוט חוסך את ההקלדה של מרחב השמות / המשתנה שעליו בוצע ה with, וכך גם במקרה שלנו ב forEach, בגלל שהוא בתוך בלוק של with על המערך לא צריך לרשום את שם המערך.
אגב זו תכונה מאוד בעייתית איך שמימשו אותה ב JS, ב VB לדוגמה אתה לא צריך להקליד את שם המשתנה אבל צריך להקליד נקודה במקום,
במימוש הזה זה יכול לגרום לבלבול, לדוגמה כאן הוא ידפיס את x מתוך o, שזה לא קריא בכלל:

function test(o,x) { with(o) {alert(x);}}
var o = {x:'test1'};
test(o,'test2');

ואם אין x ב o אז הוא כן ידפיס את הפרמטר x:

function test(o,x) { with(o) {alert(x);}}
var o = {u:'test1'};
test(o,'test2');

לעיון נוסף
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with

פורסם במקור בפורום CODE613 ב18/08/2015 11:49 (+03:00)

@אהרן

עדיין לא הבנתי כמה דברים

for(ll=!+[]+!![];ll<_+(+!![]);ll++) {
      lll=+!![];

היתה הצהרה רק על משתנה L מאיפה צמח LL ו-LLL??

forEach(alert);

מאיפה הוא יודע על איזה מערך לבצע forEach??

א. עצם זה שאתה מקצה לזה ערך זה כמו הכרזה על משתנה
זה מאוד מסוכן ובשביל למנוע את זה יש את strict mode
ב. את זה עושה ה with

פורסם במקור בפורום CODE613 ב18/08/2015 10:21 (+03:00)

נכון שדרושה משמעת עצמית בכתיבת JS, אבל זה קיים בכל שפה (אם כי פחות מ JS) יש קודים נוראיים בדוט נט..
והמוזרויות יש בכל שפה לדוגמה בדוט נט NULL זה לא סטרינג ריק וכו'
לעניות דעתי המעלות של JS הם כה גדולות ששווה להשקיע בלימוד של זה, פשוט כי זה העתיד.
עקומת הלמידה היא מתונה יחסית, אך עולה ככל שהנושאים מתקדמים.

לגבי הפונקציה שלעיל, היא עושה לופ על הפרמטר _ שמועבר אליה משתמשת עם with שזה בדיוק כמו with בVB, מוסיפה ערכים לarray ומציג את הarray ב alerts בסוף מחזירה תמיד 42 (משרשרת 4 ו 2), פשוט true ב JS שווה 1 ומערך ריק שווה false.

פורסם במקור בפורום CODE613 ב04/08/2015 11:42 (+03:00)

יש משהו בדבריך, זה פחות התחום שלי, ANYWAY התשובה שלי הייתה על "בלי תוכנה".

פורסם במקור בפורום CODE613 ב04/08/2015 13:55 (+03:00)

דרך המלך זה IIS
http://www.iis.net/learn/publish/using-the-ftp-service/creating-a-new-ftp-site-in-iis-7

פורסם במקור בפורום CODE613 ב04/08/2015 13:12 (+03:00)

מהטעם הנ"ל גם אני לא ממליץ על קפיצה למים על חשבון הלקוח.
מצד שני יש לקוחות שרוצים לשלם ממש זול ולא אכפת להם האיכות, (שזו טעות איומה מצד הלקוח לדעתי) ואם אתה מוצא לקוח כזה שמסכים שתקפוץ למים יחד איתו זאת יכולה להיות התחלה טובה, רק חשוב להתייעץ עם מתכנת מנוסה לפני הקפיצה לראות שהפרוייקט ריאלי למידותיך, לעשות תיאום ציפיות, ולקפוץ למים - לטבוע או לצוף.
כדאי מאוד גם במקרה כזה למצוא מתכנת מומחה שייעץ פה ושם וישמש כ"מציל" במים שאין להם סוף. . .

פורסם במקור בפורום CODE613 ב02/08/2015 15:52 (+03:00)

ואני לתומי חשבתי שהמטרה בפורום דנן הוא לעזור לאנשים המתחילים את דרכם בעולם התכנות ולשם כך השקעתי פה עד היום מזמני
נ.ב. נכתב אחרי שסיימתי את התוספת (למודל qlikview, אגב) ללקוח שלי. . .

פורסם במקור בפורום CODE613 ב30/07/2015 02:32 (+03:00)

הבעיה שכאלו ספריות מספקות רק חלק זעיר מהעושר העצום של SQL
שאפו על הלינק (הראשון) לבניה הדינאמית של linq.. הפתיע אותי
..

פורסם במקור בפורום CODE613 ב26/07/2015 23:51 (+03:00)

אני מעדיף LINQ לפעולות שאני יודע מראש מה אני הולך לבצע, למרות שאין להשוות את הביצועים ל SQL, לרשום טבלה ל DB זה גם מעמיס על הביצועים.

אבל אכן מימשתי בעבר כזה דבר, רצו שאני יפתח מודול קליטת דפי בנק ל SAP (למי שלא ידע - אני מתמחה בSAP BUSINESS ONE) וזה חברה בינלאומית עם המון בנקים ופורמטים שונים אז הלכתי על ארכיטקטורה כזו:
אני קולט את הקובץ ורושם את תוכן הקובץ לטבלה כמו שהוא - מחולק לשורות, ואז כל פורמט שאני מפתח הוא בעצם שאילתת SQL שהסטרינג שלה נשמר בטבלה ואני מריץ את הסטרינג הזה מול הטבלה שמכילה את תוכן הקובץ ויש לי גמישות מקסימלית, עם כמה פונקציות עזר ב SQL כמו split לימדתי אותם לעבוד עם זה, והיום הם כבר לא צריכים אותי לפתח קליטת פורמטים חדשים . . .

פורסם במקור בפורום CODE613 ב26/07/2015 23:13 (+03:00)

אין דרך נורמלית
אם אתה מתעקש תמיד יימצא פתרון, לדוגמה תייצא את הטבלה לסטרינג עם writexml ועל זה תחבר שאילתה כזו

(עדיין תצטרך קונקשן לsql)

פורסם במקור בפורום CODE613 ב26/07/2015 22:05 (+03:00)

יש הרבה ספריות מעולות לזה - אחת הטובות:

מדריך ל MVC

פורסם במקור בפורום CODE613 ב21/07/2015 15:24 (+03:00)

@ארכיטקט

WEB!
אין עתיד לשום דבר אחר. חד משמעית.

ג"א מצטרף להנ"ל.
HTML5+CSS3+JS משמש היום לפיתוח להמון פלטפורמות לדוגמה לאפליקציות מובייל וכו' ורק ילך ויתרחב

פורסם במקור בפורום CODE613 ב20/07/2015 14:49 (+03:00)

את שיטה א' תוריד מהפרק - אין ספק שלא צריך לשמור נתוני אשראי ופרטי בנק באותה טבלה.
לשמור עמודה אחת של סוג אמצעי התשלום ועמודה נוספת של מזהה התשלום זוהי פרקטיקה מאוד נפוצה ונכונה - אין ספק שניכר בך הפוטנציאל. . .

לגבי בעייתיות בהמשך עם שאילתות:
העיקרון הוא שאין שום מקום לפשרות כשהתוצאה היא bad design - (נתרגם לארכיטקטורה גרועה?)
תאמין לי ארכיטקטורה גרועה היא היא זו שתסבך אותך הכי הרבה, אתה תתקע בכל מיני פינות וגם בחיפושים אחרי פתרון באינטרנט תחוש בודד, כי אף אחד לא עשה את הדברים עקום כמוך, וממילא לא תמצא פתרון, תיאלץ לפתור לבד - מה שיגרום לך לסבך עוד ועוד את התוכנה עד אין קץ.

אתן לך דוגמה: אתה יכול לפתור את הבעיה בעזרת פתרון פשוט - בכרטיס הלקוח לשמור בעמודה אחת את אמצעי התשלום ולתת לכל כרטיסי האשראי מזהה אי זוגי ולכל ההו"ק מזהה זוגי, ככה אתה גם יכול לדעת בחישוב פשוט איזה אמצעי תשלום זה וגם לאחד אותם לשדה אחד. נפלא, נכון?
זהו שלא. מה קורה אם מחר הוא ירצה להוסיף תשלום באמצעות paypal? תעשה כפולות של 3? אה, רגע, זה אי זוגי! אז מהיום, ועל העבר נעשה UPDATE, בעצם זה PK.. וככה נראה הפתח לכל הצרות. . . למעשה, גם אז תוכל לפתור את הבעיה אבל ברמת סיבוכיות שתדרוש ממך עבודה רבה מאוד.

מידה טובה מרובה:
אם תלך בדרך הישר ולא תחפש קיצורי דרך של ארכיטקטורה גרועה, אולי תתקל פה ושם באתגרים טכנולוגיים. אך תמצא שפע של עזרה ברשת ודוגמאות של אנשים שכבר עשו זאת לפניך, וההתמודדות תהיה בטווח הסביר, חוץ מזה שטיפול באגים יהיה פשוט יותר ושינויים בתוכנה יהיו קלים יותר.

פורסם במקור בפורום CODE613 ב12/07/2015 22:03 (+03:00)

@אהרן

לא נראה לי שמישהו יענה לי כאן על שאלות ב-JS.

Try me :?:

פורסם במקור בפורום CODE613 ב12/07/2015 01:02 (+03:00)