упростить мою групповую

Question

Привет, я хотел бы вернуть данные группы обратно на уровень пользовательского интерфейса.

Вот как я хочу сделать упростить группирование "GenerationDate" и вернуть данные в List <> обратно в gridView пользовательского интерфейса.,я нахожу это очень хлопотным, так как я должен сделать forloop.Также в слое пользовательского интерфейса я получил еще один forloop для этой простой группы.Не могли бы вы помочь упростить это?

public List<SalaryTracker> GetSalaryTrackerOrderByGenerationDate(int tutorId)
{
    List<SalaryTracker> salary = new List<SalaryTracker>();
    using (leDataContext db = new leDataContext())
    {
        try
        {
            var r = 
                from s in db.SalaryTrackers
                where s.StaffId == 2 && s.PaymentDate == null
                group s by s.GenerationDate into g
                where g.Count() > 0
                select new
                {
                    date = g.Key, totalSalary = g.Sum(p => p.SalaryAmount)
                };

            foreach (var rr in r)
            {
                SalaryTracker m = new SalaryTracker();
                m.GenerationDate = rr.date;
                m.SalaryAmount = rr.totalSalary;
                salary.Add(m);
            }

            return salary; 
        }
        catch (Exception ex)
        {
            Logger.Error(typeof(SalaryTracker), ex.ToString());
            throw;
        }                    
    }
}

--------------- GUI

totalCommissionsGroup = salary.GetSalaryTrackerOrderByGenerationDate(tutor.Id);

IList<SalaryTracker> rr = (
    totalCommissionsGroup.GroupBy(x => x.GenerationDate)
    .Select(g => new SalaryTracker
    {
        MonthId = g.Key.Month,
        MonthToPay = common.GetMonthName(Convert.ToInt16(g.Key), true),
        SalaryAmount = g.Sum(x => x.SalaryAmount)
    })).ToList<SalaryTracker>();  

gvSalaryPayment.DataSource = rr;           

Я делаю это, чтобы получить MonthToPay в строке

Answer 1

public List<SalaryTracker> GetSalaryTrackerOrderByGenerationDate(int tutorId)
{
    using (var db = new leDataContext())
    {
        try
        {
            return (
                from s in db.SalaryTrackers
                where s.StaffId == 2 && s.PaymentDate == null
                group s by s.GenerationDate into g
                select new
                { 
                    MonthId = g.Key.Month,
                    // I don't know what "common" is in your UI code, 
                    // I am just using GetMonthName here
                    MonthToPay = GetMonthName(Convert.ToInt16(g.Key), true), 
                    SalaryAmount = g.Sum(p => p.SalaryAmount)  
                })
                .AsEnumerable()
                .Select(x => new SalaryTracker 
                { 
                    MonthId = x.MonthId,
                    MonthToPay = x.MonthToPay, 
                    SalaryAmount = x.SalaryAmount  
                })
                .ToList();
        }
        catch (Exception ex)
        {
            Logger.Error(typeof(SalaryTracker), ex.ToString());
            throw;
        }
    }
}

Answer 2

Я согласен с рефакторингом Mahesh Velaga (+1 за это) и хочу добавить, что ошибки регистрации на этом уровне приложения являются необычными.Особенно, когда вы решаете сбросить исключение любым способом.Поэтому я предлагаю вам удалить полную try catch с ведением журнала ошибок и войти только в корень вашего приложения (если вы этого еще не сделали).Это делает ваш код намного чище.

Когда вы это сделаете, вы увидите, что остался хороший читаемый метод, почти ничего кроме бизнес-логики.

ОБНОВЛЕНИЕ

Но если мы не поместим 'try catch' в слой datamodel, как основной вызывающий объект поймает ошибку?Я использовал этот шаблон в течение многих лет .. пожалуйста, поправьте меня, если я не прав.Обратитесь к этой ссылке .

Поймите, как вы делаете в своем вопросе или делаете, как показано в статье , на которую вы ссылаетесь , которую вы предоставляете, почти всегдаОптимальный по нескольким причинам:

• Захват, ведение журнала и повторная пересылка на уровне обслуживания неудачны, потому что в итоге вы получите двойные записи об этой ошибке в вашей системе ведения журнала просто потому, что вам нужноВ любом случае входите в систему на верхнем уровне приложения, так как в противном случае вы пропустите ошибки регистрации, которые не происходят из уровня обслуживания.Игнорирование ошибки (путем , а не ее повторного выброса) также является плохой идеей, потому что клиент вряд ли когда-либо продолжит работу при возникновении ошибки.
• Перехват на уровне представления, как показано в ссылка на статью также вызывает сожаление, поскольку таким образом вы не регистрируете ошибки, но, что более важно, вы даете пользователю, возможно, технические и неясные сообщения об ошибках (возможно, даже на иностранном языке), которые они не понимаюти это расстроит их.Хуже того, это может привести к утечке информации, которая позволит хакерам увидеть, что происходит под поверхностью при атаке вашего приложения (в случае публичного веб-приложения).

Это не означает, чтовы не можете отображать какую-либо информацию об ошибках для пользователей, но делаете это только для исключений, которые вы явным образом выдавали для представления информации об ошибках для пользователей.Например:

try
{
    // Call into service layer
}
catch (BusinessLayerException ex)
{
    this.ValidationSummary1.Add(new CustomValidator
    {
        ErrorMessage = ex.Message, IsValid = false
    });
}

В этом примере BusinessLayerException - это особое исключение, которое выдается из бизнес-уровня, которое содержит сообщения об ошибках, понятные для пользователя (возможно, с локализованным сообщением об ошибке, если вашПриложение используется пользователями на нескольких языках).

За всеми остальными исключениями большую часть времени вы не хотите показывать пользователю это точное сообщение об ошибке, потому что вы не представляете, что пошло не так и насколько серьезноошибка и какую информацию содержит исключение.Лучше всего иметь как можно меньше логики обработки ошибок на уровне представления и обрабатывать ее в одном месте на верхнем уровне приложения.Здесь вы гарантируете, что страница ошибки отображается пользователю в этом случае, и вы гарантируете, что ошибка регистрируется в системе регистрации.

Вы можете настроить ASP.NET, чтобы показать пользовательскийстраница ошибки в случае ошибки.Вот пример:

<customErrors mode="RemoteOnly" 
    defaultRedirect="~/ErrorPage.htm">
</customErrors>

ErrorPage.htm может отображать общую информацию, такую ​​как общая страница ошибки «это наша ошибка», здесь, в Stackoverflow.Возможно, некоторые контактные данные службы поддержки, номер вашего домашнего телефона, чтобы они могли звонить вам ночью; -)

Реализуя метод Application_Error в global.asax, вы можете в одном месте в приложениирегистрировать необработанные исключения:

void Application_Error(object sender, EventArgs e)
{
    Exception ex = Server.GetLastError();

   // Log the exception here.
}

Убедитесь, что вы записали всю информацию об необходимой ошибке, такую ​​как трассировка стека, сообщение об ошибке, тип исключения и все внутренние исключения, которые могут возникнуть.

Надеюсь, это поможет.