Наша компания предоставляет набор различных приложений, которые манипулируют данными в базе данных. Каждое приложение имеет свою специфическую бизнес-логику, но все приложения имеют общий поднабор бизнес-правил. Обычные вещи инкапсулируются в кучу устаревших COM-библиотек DLL, написанных на С++, которые используют "классический ADO" (обычно они вызывают хранимые процедуры, иногда они используют динамический SQL). Большинство из этих DLL имеют XML-методы (не говоря уже о методах, основанных на собственном формате!) Для создания, редактирования, удаления и извлечения объектов, а также дополнительных действий, таких как методы, которые быстро копируют и преобразуют многие объекты.
Библиотеки промежуточного ПО теперь очень старые, нашим разработчикам приложений требуется новое объектно-ориентированное (а не xml-ориентированное) промежуточное программное обеспечение, которое может быть легко использовано приложениями С#. Многие люди в компании говорят, что мы должны забыть старые парадигмы и перейти к новой классной вещи, такой Entity Framework. Они заинтригованы простотой POCOs, и они хотели бы использовать LINQ для извлечения данных (методы запросов на основе Xml для DLL не так просты в использовании и никогда не будут такими гибкими, как LINQ).
Итак, я пытаюсь создать макет для упрощенного сценария (реальный сценарий гораздо сложнее, и здесь я опубликую просто упрощенное подмножество упрощенного сценария!). Я использую Visual Studio 2010, Entity Framework 5 Code First, SQL Server 2008 R2. Пожалуйста, помилуй, если я сделаю глупые ошибки, я новичок в Entity Framework. Поскольку у меня много разных сомнений, я буду размещать их в отдельных потоках. Это первый. Унаследованные методы XML имеют такую подпись:
bool Edit(string xmlstring, out string errorMessage)
С таким форматом:
<ORDER>
<ID>234</ID>
<NAME>SuperFastCar</NAME>
<QUANTITY>3</QUANTITY>
<LABEL>abc</LABEL>
</ORDER>
В методе "Редактирование" реализована следующая бизнес-логика: при изменении количества "автоматическое масштабирование" должно применяться ко всем ордерам, которые имеют одну и ту же метку. Например. существует три порядка: OrderA имеет величину = 3, label = X. OrderB имеет величину = 4, метку = X. OrderC имеет величину = 5, label = Y. Я вызываю метод Edit, который снабжает новую величину = 6 для OrderA, то есть я удваиваю количество OrderA. Затем, согласно бизнес-логике, количество OrderB должно быть автоматически удвоено и должно стать 8, потому что OrderB и OrderA имеют одну и ту же метку. OrderC не может быть изменен, поскольку он имеет другую метку.
Как я могу воспроизвести это с помощью классов POCO и Entity Framework? Это проблема, потому что старый метод Edit может изменять только один порядок за раз, в то время как Entity Framework может изменять множество ордеров при вызове SaveChanges. Кроме того, один вызов SaveChanges может также создавать новые Заказы. Временные предположения, только для этого теста: 1) если одновременно изменяется количество заказов, и коэффициент масштабирования для всех из них не одинаковый, происходит масштабирование НЕТ; 2) недавно добавленные ордера автоматически не масштабируются, даже если они имеют одну и ту же метку масштабированного порядка.
Я попытался реализовать его, переопределив SaveChanges.
Класс POCO:
using System;
namespace MockOrders
{
public class Order
{
public Int64 Id { get; set; }
public string Name { get; set; }
public string Label { get; set; }
public decimal Quantity { get; set; }
}
}
Файл миграции (для создания индексов):
namespace MockOrders.Migrations
{
using System;
using System.Data.Entity.Migrations;
public partial class UniqueIndexes : DbMigration
{
public override void Up()
{
CreateIndex("dbo.Orders", "Name", true /* unique */, "myIndex1_Order_Name_Unique");
CreateIndex("dbo.Orders", "Label", false /* NOT unique */, "myIndex2_Order_Label");
}
public override void Down()
{
DropIndex("dbo.Orders", "myIndex2_Order_Label");
DropIndex("dbo.Orders", "myIndex1_Order_Name_Unique");
}
}
}
DbContext:
using System;
using System.Data.Entity;
using System.Data.Entity.ModelConfiguration;
using System.Linq;
namespace MockOrders
{
public class MyContext : DbContext
{
public MyContext() : base(GenerateConnection())
{
}
private static string GenerateConnection()
{
var sqlBuilder = new System.Data.SqlClient.SqlConnectionStringBuilder();
sqlBuilder.DataSource = @"localhost\aaaaaa";
sqlBuilder.InitialCatalog = "aaaaaa";
sqlBuilder.UserID = "aaaaa";
sqlBuilder.Password = "aaaaaaaaa!";
return sqlBuilder.ToString();
}
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Configurations.Add(new OrderConfig());
}
public override int SaveChanges()
{
ChangeTracker.DetectChanges();
var groupByLabel = from changedEntity in ChangeTracker.Entries<Order>()
where changedEntity.State == System.Data.EntityState.Modified
&& changedEntity.Property(o => o.Quantity).IsModified
&& changedEntity.Property(o => o.Quantity).OriginalValue != 0
&& !String.IsNullOrEmpty(changedEntity.Property(o => o.Label).CurrentValue)
group changedEntity by changedEntity.Property(o => o.Label).CurrentValue into x
select new { Label = x.Key, List = x};
foreach (var labeledGroup in groupByLabel)
{
var withScalingFactor = from changedEntity in labeledGroup.List
select new
{
ChangedEntity = changedEntity,
ScalingFactor = changedEntity.Property(o => o.Quantity).CurrentValue / changedEntity.Property(o => o.Quantity).OriginalValue
};
var groupByScalingFactor = from t in withScalingFactor
group t by t.ScalingFactor into g select g;
// if there are too many scaling factors for this label, skip automatic scaling
if (groupByScalingFactor.Count() == 1)
{
decimal scalingFactor = groupByScalingFactor.First().Key;
if (scalingFactor != 1)
{
var query = from oo in this.AllTheOrders where oo.Label == labeledGroup.Label select oo;
foreach (Order ord in query)
{
if (this.Entry(ord).State != System.Data.EntityState.Modified
&& this.Entry(ord).State != System.Data.EntityState.Added)
{
ord.Quantity = ord.Quantity * scalingFactor;
}
}
}
}
}
return base.SaveChanges();
}
public DbSet<Order> AllTheOrders { get; set; }
}
class OrderConfig : EntityTypeConfiguration<Order>
{
public OrderConfig()
{
Property(o => o.Name).HasMaxLength(200).IsRequired();
Property(o => o.Label).HasMaxLength(400);
}
}
}
Кажется, что работает (конечно, запрет ошибок), но это был пример всего с одним классом: у реального производственного приложения могут быть сотни классов! Я боюсь, что в реальном сценарии, с множеством ограничений и бизнес-логики, переопределение SaveChanges может быстро стать длинным, загроможденным и подверженным ошибкам. Некоторые коллеги также обеспокоены работой. В наших устаревших DLL многие бизнес-логики (например, "автоматические" действия) живут в хранимых процедурах, некоторые коллеги опасаются, что подход, основанный на SaveChanges, может ввести слишком много круговых поездок и затруднить работу. В переопределении SaveChanges мы также можем ссылаться на хранимые процедуры, но как насчет целостности транзакций? Что делать, если я вношу изменения в базу данных прежде чем я назову "base.SaveChanges()", и "base.SaveChanges()" не удается?
Есть ли другой подход? Я что-то упускаю?
Большое спасибо!
Деметрио
p.s. Кстати, существует ли разница между переопределением SaveChanges и регистрацией на событие "SavingChanges"? Я прочитал этот документ, но он не объясняет, есть ли разница: http://msdn.microsoft.com/en-us/library/cc716714(v=vs.100).aspx
Этот пост: Entity Framework SaveChanges - настроить поведение?
говорит, что "при переопределении SaveChanges вы можете поставить пользовательскую логику до и после вызова base.SaveChanges". Но существуют ли другие оговорки/преимущества/недостатки?