Элегантный вариант заключается в написании метода расширения (см. ниже) для класса DataTable .net framework.
Этот метод расширения можно вызывать следующим образом:
using System;
using System.Collections.Generic;
using System.Linq;
using Excel = Microsoft.Office.Interop.Excel;
using System.Data;
using System.Data.OleDb;
DataTable dt;
// fill table data in dt here
...
// export DataTable to excel
// save excel file without ever making it visible if filepath is given
// don't save excel file, just make it visible if no filepath is given
dt.ExportToExcel(ExcelFilePath);
Метод расширения для класса DataTable:
public static class My_DataTable_Extensions
{
// Export DataTable into an excel file with field names in the header line
// - Save excel file without ever making it visible if filepath is given
// - Don't save excel file, just make it visible if no filepath is given
public static void ExportToExcel(this DataTable tbl, string excelFilePath = null) {
try {
if (tbl == null || tbl.Columns.Count == 0)
throw new Exception("ExportToExcel: Null or empty input table!\n");
// load excel, and create a new workbook
var excelApp = new Excel.Application();
excelApp.Workbooks.Add();
// single worksheet
Excel._Worksheet workSheet = excelApp.ActiveSheet;
// column headings
for (var i = 0; i < tbl.Columns.Count; i++) {
workSheet.Cells[1, i + 1] = tbl.Columns[i].ColumnName;
}
// rows
for (var i = 0; i < tbl.Rows.Count; i++) {
// to do: format datetime values before printing
for (var j = 0; j < tbl.Columns.Count; j++) {
workSheet.Cells[i + 2, j + 1] = tbl.Rows[i][j];
}
}
// check file path
if (!string.IsNullOrEmpty(excelFilePath)) {
try {
workSheet.SaveAs(excelFilePath);
excelApp.Quit();
MessageBox.Show("Excel file saved!");
}
catch (Exception ex) {
throw new Exception("ExportToExcel: Excel file could not be saved! Check filepath.\n"
+ ex.Message);
}
} else { // no file path is given
excelApp.Visible = true;
}
}
catch (Exception ex) {
throw new Exception("ExportToExcel: \n" + ex.Message);
}
}
}
Мы используем рабочий процесс конечного автомата для управления парой процессов запроса на обслуживание приблизительно с 10 состояниями каждый. Я не уверен, ли это, были 100% правильный выбор, потому что реализация простого дизайна конечного автомата будет более простой (возможно, мы пострадали здесь от BDUF).
самая большая оборотная сторона для нас была кривой обучения. Я имею в виду, рабочий процесс является практически разделенным вниз версия biztalk (бесплатно!).
Первое, что пришло на ум, это области, которым мы извлекли выгоду из WF:
, я всегда пытаюсь иметь в виду, что это действительно - основа. Как разработчик/архитектор, необходимо принять на себя обязательство создавать что-то полезное сверху его.
Я использовал Windows Workflow в веб-приложении, разработанном для управления жизненным циклом запросов контроля изменений в корпоративной системе. Я по общему признанию возился вокруг в нем, и определенно не сделал большого количества вещей правильно, но это работало вполне прилично, и я был удовлетворен тем, как легко я мог изменить правила, не пишущий еще больше кода.
Однако, как только я прокрутился от проекта, человек, который наследовал его, решил, что не любил WF или не хотел изучать его, таким образом, приложение умерло, и они вернулись к использованию электронных писем и телефонных вызовов. Так реализация была успешна, но инвестиции были в конечном счете отходами.
привет Tom, я действительно не думаю сияния WF хорошо, когда мы используем причину веб-приложений, скорее всего, мы собираемся использовать DB для сохранения состояния, Вы точно задали вопрос, который я имел на своем уме, мы использовали WF в нашей продуктивной среде и ее предоставлении большой проблемы, когда мы обновляем от одной версии до другого, во-вторых, это имеет много ограничений т.е. это не поддерживает окружающую транзакцию, я думаю, что мы должны ожидать Версии 4 или 5, чтобы видеть, имеет ли это что-нибудь лучше для предложения
Мой опыт был подобен В космос, мы посмотрели на использование WF для управления комплексом и варьировались, заказывая процесс в сценариях variuos B2B. В последний раз я слышал, что они были в процессе потрошения его.
я думаю, что многим разработчикам трудно думать с точки зрения рабочего процесса.
Я развернул 3 приложения. 2 приложения ASP.NET, и 1 из рабочего процесса был развернут на среде SharePoint. Оглядывание назад, я думаю, что инвестиции стоили того. Как предыдущий сказанный парень, WF является платформой, на которую необходимо положиться. Это - еще один слой для волнения о, но преимущества перевешивают затраты.