如果添加一个继承自某些东西的类，如果它改变了代码的行为，是否违反了坚实的原则？ [英] Is adding a class that inherits from something a violation of the solid principles if it changes the behavior of code?

问题描述

我努力使我的代码能够使用不同的连接字符串先运行代码EF迁移，最后使其正常工作。

我的答案中概述了我使用的方法到此问题

让我困扰的是，为了能够使用不同的连接字符串运行相同的代码，我不得不

1）求助于全局设置存储连接字符串

2）介绍一个类，该类的存在导致代码的行为不同。

这与我习惯的工作方式截然不同。这里使用的技术是否违反了坚实的原则？还有其他不违反原则的方式吗？

更新：
另一种方法-概述了可能更明智此处

解决方案

< blockquote>

（所有这些都与这里的内容有关
Database.SetInitializer实际如何工作（EF代码首先创建数据库并使用多个连接字符串应用迁移）-但方向却截然不同-所以我认为分开是有意义的。在此之前阅读）

更新：

在这里变得越来越有趣。 我确实设法重现了您实际面临的问题。以下是我认为正在发生的事情的简短细目：

首先，这很愉快：

  Database.SetInitializer（new CreateAndMigrateDatabaseInitializer< MyContext，MyProject.Migrations.Configuration>（））; 
 for（var flip = false; true; flip =！flip）
 {
使用（var db = new MyContext（flip？ Name = MyContext： Name = OtherContext）） 
 {
 //插入一些记录... 
 db.SaveChanges（）; 
} 
} 
  

（我使用了自定义初始化程序来自我的另一篇文章，该文章控制着迁移/创建

在没有初始化程序的情况下效果很好。一旦打开它，我就会遇到一些奇怪的问题。

我删除了Db-s（每个连接两个）。我希望要么不起作用，要么创建一个数据库，然后在下一遍创建另一个数据库（就像那样，不进行迁移，只是创建初始化程序）。

发生了什么，令我惊讶的是，它实际上是在第一个
传递中创建了两个数据库吗？

然后，作为一个好奇的人：），我在 MyContext ctor上设置了断点，并进行了调试通过迁移器/初始化器。再次为空/没有db-s等。

它在 flip 内的呼叫中创建了第一个实例。然后，在首次访问模型时，它调用了初始化程序。迁移者接管了（没有db-s）。在 migrator.Update（）; 期间，它实际上构造了 MyContext （我猜是通过Configuration中的通用参数） -并调用默认空ctor。默认情况下具有其他连接/名称-并同时创建另一个Db。

所以，我认为这可以解释您遇到的情况。以及为什么必须创建工厂来支持上下文创建。那似乎是唯一的方法。并设置一些 AppDomain宽泛的连接字符串（您确实确实发现了这一点），而不会被空的ctor调用覆盖。

我看到的解决方案-您只需要通过工厂运行所有内容-并在其中进行翻转连接（无需静态连接即可） ，只要您的工厂是单身人士。

这对于正式的$实际上根本不起作用（至少是我的测试） b $ b MigrateDatabaseToLatestVersion 初始化程序-以及我
使用另一个变量的原因。

I struggled to enable my code to run code first EF migrations using different connection strings, and finally got it working.

The method I used is outlined in my answer to this question

What bothers me is that in order to be able to run the same code using different connection strings I had to

1) Resort to a global setting to store the connection string

2) Introduce a class whose very presence caused the code to behave differently.

This is so different to the way I am used to working. Is the technique used here violating the solid principles? Is there any other way of doing it that does not violate the principles?

UPDATE: A different approach - possibly more sensible is outlined here

解决方案

(all this is is related to what's in here How does Database.SetInitializer actually work? (EF code-first create database and apply migrations using several connection strings) - but was getting into entirely different direction - so I think it makes sense to be separated. Read there before this)

Update:

It is getting interesting here. I did manage to reproduce the problems you're facing actually. Here is a short breakdown on what I think it's happening:

First, this worked 'happily':

Database.SetInitializer(new CreateAndMigrateDatabaseInitializer<MyContext, MyProject.Migrations.Configuration>());
for (var flip = false; true; flip = !flip)
{
    using (var db = new MyContext(flip ? "Name=MyContext" : "Name=OtherContext"))
    {
        // insert some records...
        db.SaveChanges();
    }
}

(I used custom initializer from my other post, which controls migration/creation process together)

That worked fine w/o an Initializer. Once I switched that on, I ran into some curious problems.

I deleted Db-s (two, for each connection). I expected to either not work, or create one db, then another in the next pass (like it did, w/o migrations, just 'Create' initializer).

What happened, to my surprise - is it actually created both databases on the first pass ??

Then, being a curious person:), I put breakpoints on the MyContext ctor, and debugged through the migrator/initializer. Again empty/no db-s etc.

It created first instance on my call within the flip. Then on the first access to 'model', it invoked the initializer. Migrator took over (having had no db-s). During the migrator.Update(); it actually constructs the MyContext (I'm guessing via generic param in Configuration) - and calls the 'default' empty ctor. That had the 'other connection/name' by default - and creates the other Db all as well.

So, I think this explains what you're experiencing. And why you had to create the 'Factory' to support the Context creation. That seems to be the only way. And setting some 'AppDomain' wide 'connection string' (which you did discover well actually) which isn't 'overriden' by an empty ctor call.

Solution that I see is - you just need to run everything through factory - and 'flip' connections in there (no need for static connection, as long as your factory is a singleton.

This actually doesn't work at all (my test at least) with an official MigrateDatabaseToLatestVersion initializer - and the reason why I used the other one.

这篇关于如果添加一个继承自某些东西的类，如果它改变了代码的行为，是否违反了坚实的原则？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！