I am trying to find the best way to initialise device drivers (maintained by production staff). Configuration generally contains serial ports and other information which production staff may need to change if the underlying hardware for the device driver changes.
e.g.
using System.IO.Ports;
public class Scanner : IDriver
{
public SerialPort SerialPort { get; private set; }
public String Id { get; private set; }
public String DisplayName { get; private set; }
public Scanner(SerialPort serialPort, String id, String displayName)
{
SerialPort = serialPort;
Id = id;
DisplayName = displayName;
}
}
public class TestMethod
{
public Scanner MainScanner { get; private set; }
public Scanner SecondaryScanner { get; private set; }
public TestMethod (Scanner main, Scanner secondary)
{
MainScanner = main;
SecondaryScanner = secondary;
}
}
How can I use a DI container and still make the configuration changeable at runtime? I would like to avoid using the XML configuration that comes with the DI containers as I expect the production staff to modify these (configuration) files often. A separate configuration file would be prefered.
A possible implementation of xml configuration
<DeviceDrivers>
<Driver name="main" id="IX234" displayName="main scanner">
<SerialPort name="serialPort" portName="COM8" baudRate="11560" parity="None" dataBits="8" stopBits="None">
</Driver>
<Driver name="secondary" id="IX2E3" displayName="secondary scanner">
<SerialPort name="serialPort" portName="COM9" baudRate="11560" parity="None" dataBits="8" stopBits="None">
</Driver>
</DeviceDrivers>
SerialPort itself need to be intialised from the configuration file.
Thanks
PS: I was considering Ninject, but not sure if I can pull this off.
First of all I have not worked on Ninject but have some idea about Unity. Secondly, I hope I understood your problem correctly that you would want the mentioned XML configuration for DeviceDrivers to go as a separate config file to which production staff will not have access.
So for the said scenario I think you would have to have two different mapping for IDriver to Scanner (both should preferably be named, say, 'Main' and 'Secondary') and in both you can specify initialization values for instances of SerialPort as also mentioned in your XML config. All these configuration will be part of a separate file that will be loaded to Unity container. To see how to load container with configuration from multiple config files please refer to http://msdn.microsoft.com/en-in/library/ff660935(v=pandp.20).aspx.
Related
The definition of my interface is as follows:
public interface IApplicationSettings
{
string LoggerName { get; }
string NumberOfResultsPerPage { get; }
string EmailAddress { get; }
string Credential { get; }
}
The implementation of this interface is given below:
public class WebConfigApplicationSettings : IApplicationSettings
{
public string LoggerName
{
get { return ConfigurationManager.AppSettings["LoggerName"]; }
}
public string NumberOfResultsPerPage
{
get { return ConfigurationManager.AppSettings["NumberOfResultsPerPage"]; }
}
public string EmailAddress
{
get { return ConfigurationManager.AppSettings["EmailAddress"]; }
}
public string Credential
{
get { return ConfigurationManager.AppSettings["Credential"]; }
}
}
I also created a factory class to obtain the instance of the concrete implementation of WebConfigSettings as follows:
public class ApplicationSettingsFactory
{
private static IApplicationSettings _applicationSettings;
public static void InitializeApplicationSettingsFactory(
IApplicationSettings applicationSettings)
{
_applicationSettings = applicationSettings;
}
public static IApplicationSettings GetApplicationSettings()
{
return _applicationSettings;
}
}
Then I resolved dependency as follows:
public class DefaultRegistry : Registry {
public DefaultRegistry() {
Scan(
scan => {
scan.TheCallingAssembly();
scan.WithDefaultConventions();
scan.With(new ControllerConvention());
});
For<IApplicationSettings>().Use<WebConfigApplicationSettings>();
ApplicationSettingsFactory.InitializeApplicationSettingsFactory
(ObjectFactory.GetInstance<IApplicationSettings>());
}
}
Now when i running my application it throw me following exception:
Exception has been thrown by the target of an invocation.
and the Inner Exception is
No default Instance is registered and cannot be automatically determined for type 'Shoppingcart.Infrastructure.Configuration.IApplicationSettings'\r\n\r\nThere is no configuration specified for Shoppingcart.Infrastructure.Configuration.IApplicationSettings\r\n\r\n1.) Container.GetInstance(Shoppingcart.Infrastructure.Configuration.IApplicationSettings)\r\n
I am using StructureMap for MVC5
The reason your code isn't working is because when you call ObjectFactory.GetInstance<IApplicationSettings>(), your registry hasn't been registered and thus, StructureMap's configuration is incomplete.
I believe what you're trying to do is the following (tested and works):
public class ApplicationSettingsFactory
{
public ApplicationSettingsFactory(WebConfigApplicationSettings applicationSettings)
{
_applicationSettings = applicationSettings;
}
private static IApplicationSettings _applicationSettings;
public IApplicationSettings GetApplicationSettings()
{
return _applicationSettings;
}
}
With your registry configured like this:
public DefaultRegistry() {
Scan(scan => {
scan.TheCallingAssembly();
scan.WithDefaultConventions();
scan.With(new ControllerConvention());
});
this.For<IApplicationSettings>().Use(ctx => ctx.GetInstance<ApplicationSettingsFactory>().GetApplicationSettings());
}
I can't really tell you why your registration fails in StructureMap, but if you allow me, I would like to feedback on your design.
Your design and code violates a few basic principles:
You are violating the Interface Segregation Princple (ISP).
The ISP describes that interfaces should be narrow (role interfaces) and should not contain more members than a consumer uses. You however defined an application wide IApplicationSettings interface and your intention is to inject into any consumer that needs some configuration settings. Changes are really slim however that there is a consumer that actually needs all settings. This forces the consumer to depend on all members, it makes the API more complex, while it just needs one.
You are violating the Open/Closed Principle (OCP).
The OCP describes that it should be possible to add new features without making changes to existing classes in the code base. You will however find yourself updating the IApplicationSettings interface and its implementations (you will probably have a fake/mock implementation as well) every time a new setting is added.
Configuration values aren't read at startup, which makes it harder to verify the application's configuration.
When a consumer makes a call to a property of your IApplicationSettings abstraction, you are forwarding the call to the ConfigurationManager.AppSettings. This means that if the value isn't available or incorrectly formatted, the application will fail at runtime. Since some of your configuration values will only be used in certain cases, this forces you to test every such case after you deployed the application to find out whether the system is configured correctly.
Solution
The solution to these problems is actually quite simple:
Load configuration values at start-up.
Inject configuration values directly into a component that needs that exact value.
Loading the configuration values directly at start-up, allows the application to fail fast in case of a configuration error, and prevents the configuration from being read over and over again needlessly.
Injecting configuration values directly into a component, prevents that component from having to depend on an ever-changing interface. It makes it really clear what a component is depending upon, and bakes this information in during application start-up.
This doesn't mean though that you can't use some sort of ApplicationSettings DTO. Such DTO is exactly what I use in my applications. This basically looks as follows:
public static Container Bootstrap() {
return Bootstrap(new ApplicationSettings
{
LoggerName = ConfigurationManager.AppSettings["LoggerName"],
NumberOfResultsPerPage = int.Parse(
ConfigurationManager.AppSettings["NumberOfResultsPerPage"]),
EmailAddress = new MailAddres(
ConfigurationManager.AppSettings["EmailAddress"]),
Credential = ConfigurationManager.AppSettings["Credential"],
});
}
public static Container Bootstrap(ApplicationSettings settings) {
var container = new Container();
container.RegisterSingle<ILogger>(
new SmtpLogger(settings.LoggerName, settings.EmailAddress));
container.RegisterSingle<IPagingProvider>(
new PagingProvider(settings.NumberOfResultsPerPage));
// Etc
return container;
}
In the code above you'll see that the creation of the ApplicationSettings DTO is split from the configuration of the container. This way I can test my DI configuration inside an integration test, where the start-up projects configuration file is not available.
Also note that I supply the configuration values directly to the constructors of components that require it.
You might be skeptic, because it might seem to pollute your DI configuration, because you have dozens of objects that require to be set with the same configuration value. For instance, your application might have dozens of repositories and each repository needs a connection string.
But my experience is that is you have many components that need the same configuration value; you are missing an abstraction. But don't create an IConnectionStringSettings class, because that would recreate the same problem again and in this case you aren't really making an abstraction. Instead, abstract the behavior that uses this configuration value! In the case of the connection string, create an IConnectionFactory or IDbContextFactory abstraction that allows creation of SqlConnection's or DbContext classes. This completely hides the fact that there is a connection string from any consumer, and allows them to call connectionFactory.CreateConnection() instead of having to fiddle around with the connection and the connection string.
My experience is that makes the application code much cleaner, and improves the verifiability of the application.
Thanks every one for responses. I found my solution. The solution is instead of using Default Registry I created another class for resolve the dependencies. Inside the class I used
ObjectFactory.Initialize(x =>
{
x.AddRegistry<ControllerRegistry>();
});
instead of
IContainer Initialize() {
return new Container(c => c.AddRegistry<ControllerRegistry>());
}
Then inside ControllerRegistry I resolved dependencies as follows:
// Application Settings
For<IApplicationSettings>().Use<WebConfigApplicationSettings>();
Then I called that class inside Global.asax as follows:
Bootstrap.ConfigureDependencies();
Finally inside Global.asax I resolved dependency for Factory class as follows:
ApplicationSettingsFactory.InitializeApplicationSettingsFactory
(ObjectFactory.GetInstance<IApplicationSettings>());
My entire code is given below:
Bootstrap class (newly created)
public class Bootstrap
{
public static void ConfigureDependencies()
{
ObjectFactory.Initialize(x =>
{
x.AddRegistry<ControllerRegistry>();
});
}
public class ControllerRegistry : Registry
{
public ControllerRegistry()
{
// Application Settings
For<IApplicationSettings>().Use<WebConfigApplicationSettings>();
}
}
}
Global.asax
Bootstrap.ConfigureDependencies();
ApplicationSettingsFactory.InitializeApplicationSettingsFactory
(ObjectFactory.GetInstance<IApplicationSettings>());
Looking at this code from here:
[Serializable]
public class CreateClientCommand : Command
{
public string ClientName { get; private set; }
public string Street { get; private set; }
public string StreetNumber { get; private set; }
public string PostalCode { get; private set; }
public string City { get; private set; }
public string PhoneNumber { get; private set; }
public CreateClientCommand(Guid id, string clientName, string street, string streetNumber, string postalCode, string city, string phoneNumber) : base(id)
{
ClientName = clientName;
Street = street;
StreetNumber = streetNumber;
PostalCode = postalCode;
City = city;
PhoneNumber = phoneNumber;
}
}
The Guid here is just relevant for the command. It is not the Guid of the (potentially) created aggregate root. What is the best practice to obtain this Guid and how are any potential validation errors communicated back to the the code that puts a command on the bus? For example like this:
_bus.Publish(new CreateClientCommand(
Guid.NewGuid(),
_clientDetailsReport.ClientName,
_clientDetailsReport.Street,
_clientDetailsReport.StreetNumber,
_clientDetailsReport.PostalCode,
_clientDetailsReport.City,
_clientDetailsView.PhoneNumber));
_bus.Commit();
I understand that CQRS usually implements eventual consistency. This means that it might take a while before the client is actually created. Some MVC/CQRS code uses this approach:
[HttpPost]
public ActionResult Add(DiaryItemDto item)
{
ServiceLocator.CommandBus.Send(new CreateItemCommand(Guid.NewGuid(),item.Title,item.Description,-1,item.From,item.To));
return RedirectToAction("Index");
}
Obviously, the index page might show some grid containing the DiaryItems and the user might be able to see the latest created DiaryItem (potentiality after a while). Any feedback would be very much appreciated. Thanks.
Are you asking about the distinction between an ID for the command itself, versus the ID of the entity it might create? The former would typically be an infrastructure concern, found on something like a message envelope, buried in a RPC protocol, or the like. The latter would be part of your domain. (Though in many cases, it's nice to treat the ID of an entity as an infrastructure concern as well, since you might choose it for convenience in your persistence model.)
The easiest way to do this is to use the guid that you pass on the command as the actual aggregate Id and then you have it to hand and don't have to wait for it to be communicated back down on an event
Not sure why your command has an id it confuses things ( Yes some distributed systems use this but it should be a last resort). Most developers would see this as the id of the aggregate .
Generally just create the aggregate Id and send it with the command . After all the command is creating the Entity ..
Commands should in most cases be sync so you can throw errors back . With async commands you really should have a call back for success or failure ( and async should only be used where you really have the need it adds a lot of cost to the system ) .
You don't move to the next step ( if you need a next step ) until either
A) Its a system that deals with eventual consistency, a lot of business logic does do this. eg waiting for the exchange or a 3rd party to process something , then the work is waiting for that information . ( Ie the command creates an Order but the processing of the order eg OrderDetail may not be there yet and the order has a state of Order Processing)
B) You have success , timeout or failure response to command before continuing .
I encountered a problem with multiple context in EF 6. Recently i had splitted my context into three parts and configured them as had been told here
Everything was fine, until i decided to publish via Visual Studio; because publish wizard detected only one of my context instead of three. And interestingly everytime it detects same context, i couldn't find why, neither first letter of name nor any difference from the others seem cause this.
But i couldn't publish my MVC project because of this. I have to migrate all three contexts while publishing.
After some search, i saw Update-Database command gets connectionstring parameter. This is my last option, if there isn't any way to solve publish wizard i try to update database with this code.
I haven't been able to reproduce this issue. Here are the steps I used (using Visual Studio 2013 Update 2).
Create a new MVC application. Add the following models to the project (two separate Code First models/contexts).
public class CustomerContext : DbContext
{
public DbSet<Customer> Customers { get; set; }
}
public class Customer
{
public int CustomerId { get; set; }
public string Name { get; set; }
}
public class ProductContext : DbContext
{
public DbSet<Product> Products { get; set; }
}
public class Product
{
public int ProductId { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
}
Then enable migrations, add a migration and update the local database for both contexts, using the following commands.
Enable-Migrations -ContextTypeName CustomerContext -MigrationsDirectory Migrations\Customer
Enable-Migrations -ContextTypeName ProductContext -MigrationsDirectory Migrations\Product
Add-Migration FirstMigration -ConfigurationTypeName MyWebApp.Migrations.Customer.Configuration
Add-Migration FirstMigration -ConfigurationTypeName MyWebApp.Migrations.Product.Configuration
Update-Database -ConfigurationTypeName MyWebApp.Migrations.Customer.Configuration
Update-Database -ConfigurationTypeName MyWebApp.Migrations.Product.Configuration
Then when I right-click -> Publish the project I get the option to enable migrations on App_Start for both of my contexts (and the ASP.NET Identity context too). If I understand correctly, you are not seeing your additional context(s) in this screen.
I've seen this happen when multiple DbContexts share a common connection string. By this I mean:
public class Context1: DbContext
{
public Context1()
: this("DefaultConnection")
{}
public Context1: (string connectionString)
: base(connectionString)
{}
....
}
public class Context2: DbContext
{
public Context2()
: this("DefaultConnection")
{}
public Context2: (string connectionString)
: base(connectionString)
{}
...
}
When you Publish, only one DbContext will show up under Settings > Databases. If you change "DefaultConnection" to something else then you will see the distinct DbContexts. Like this:
public class Context1: DbContext
{
public Context1()
: this("DefaultConnection")
{}
public Context1: (string connectionString)
: base(connectionString)
{}
....
}
public class Context2: DbContext
{
public Context2()
: this("DefaultConnection2")
{}
public Context2: (string connectionString)
: base(connectionString)
{}
...
}
Maybe this explains the behavior you are seeing.
If both dbContexts are using the same database (and therefore the same database connection string in web.config), how do we get Web Deploy to show them both? Do I have to create a separate (duplicate) connection string that points to the same database just to get it to show up as a separate context in the wizard?
When you want to see all contexts in the Publish dialog, you need to add another connection strings to web.config. They should have different name and be referenced from your context (name in constructor)
Visual Studio 2013
I am trying to learn asp.net MVC over at PluralSight. I created a project(dll) called eManagr.Domain with the following classes:
Department / Employee / IDepartmentDatasource
Department.cs
public class Department
{
public virtual int Id { get; set; }
public virtual string Name { get; set; }
public virtual ICollection<Employee> Employees { get; set; }
}
Employee.cs
public class Employee
{
public virtual int Id { get; set; }
public virtual string Name { get; set; }
}
IDepartmentDataSource
public interface IDepartmentDataSource
{
IQueryable<Employee> Employees { get; }
IQueryable<Department> Departments { get; }
}
I created an infrastructure folder with the following file : DepartmentDb.cs
public class DepartmentDb : DbContext, IDepartmentDataSource
{
public DbSet<Employee> Employees {get; set;}
public DbSet<Department> Departments {get; set;}
IQueryable<Employee> IDepartmentDataSource.Employees
{
get { return Employees; }
}
IQueryable<Department> IDepartmentDataSource.Departments
{
get { return Departments; }
}
}
I then created another project using MVC 4 called eManager.Web with Internet Template during the creation of the project.
When running Enable-Migration it says I have two[eWeb.Domain , eWeb.Model.Users] which then I tell it Enable-Migration with the following command:
Enable-Migration -ContextTypeName DepartmentDb
which creates the migration folder and a file called Configurations.cs
public Configuration()
{
AutomaticMigrationsEnabled = true;
}
protected override void Seed(eManager.Web.Infrastructure.DepartmentDb context)
{
context.Departments.AddOrUpdate(t => t.Name,
new Department() { Name="Engineering"},
new Department() { Name = "Sales" },
new Department() { Name = "Shipping" },
new Department() { Name = "HR" }
);
}
EDIT -- Connection String from Web.Config --
<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=aspnet-eManager.Web-20140216202751;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnet-eManager.Web-20140216202751.mdf" providerName="System.Data.SqlClient" />
When I run the following I get the following reponse:
PM> update-database
Specify the '-Verbose' flag to view the SQL statements being applied to the target database.
No pending code-based migrations.
Running Seed method.
PM>
After this runs, I suppose to see a database file in my App_Data but it does not exist and when I use SQL Server Object Explorer, the database is not created even though that is what I am trying to do.
Could you provide your connection string from Web.config?
Also, is there a Data Connection (Server Explorer -> Data Connections) named the same as your connection String?
I think, adding a parameter-less constructor to your DepartmentDb context class could solve your problem
public DepartmentDb ()
: base("name=DefaultConnection")
Where name=DefaultConnection has to be your connection string name
I noticed that you enabled your migration in the correct way, have you run:
add-migration "give it a name" ?
once this has been completed you will notice a new file in the migrations folder.
you wont be able to update database with out creating a new migration.
I just ran into something very similar. I encountered it when I was going through the following ASP.NET MVC tutorial:
https://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
In my case, the problem seemed to be that I already had a database table of that name. I had gone through the tutorial partway previously about a month ago, but was interrupted and had to abort. Even though I deleted the entire Project, it seemed that the database table name may have been retained.
I say seemed to be, because the problem disappeared with the following solution: after a 2nd delete of the project, I carefully substituted 'Contoso' for 'ContosoUniversity' in every relevant situation.
Before the problem was solved, I was repeatedly getting the (0x80131904-error) in the Package Manager Console when trying to update-database, and a notice that the mdf file could not be connected to the database. However, when I checked the appropriate directory, the mdf file was not even being created.
FYI For beginning MVC-ers in Visual Studio 2012, I do recommend going through the following MVC tutorial before the one above.
https://www.asp.net/mvc/overview/older-versions/getting-started-with-aspnet-mvc4/intro-to-aspnet-mvc-4
A MVC5 Visual Studio 2013 version is also available through that link.
The tutorial of the first paragraph makes a few jumps...
I could not have debugged the issue if I'd started with the EF5 tutorial as my first MVC project.
I have an Azure worker role with a UnitOfWork class that looks something like this:
public class UnitOfWork : IUnitOfWork
{
public MyData Db { get; private set; }
public ILoginRepository LoginRepository { get; private set; }
public ISubscriptionRepository SubscriptionRepository { get; private set; }
public UnitOfWork(MyData db,
ILoginRepository loginRepository,
ISubscriptionRepository subscriptionRepository)
{
}
}
The repositories accept a reference to the DbContext as well:
public class LoginRepository : Repository<Login>, ILoginRepository
{
public LoginRepository(MyData db) : base(db) { }
}
I would think this is pretty straight-forward.
Now, I'd like to configure my code-first DbContext in Unity so that each time a UnitOfWork is resolved a new DbContext is created and all subsequently resolved repositories get it too.
I'd think that PerResolveLifetimeManager would do the trick:
container.RegisterType<IUnitOfWork, UnitOfWork>();
container.RegisterType<MyData, MyData>(new PerResolveLifetimeManager());
But it does not. I get all these weird SQL-related errors, such as:
"New transaction is not allowed because there are other threads running in the session."
What gives?
You are talking about PerResolveLifetimeManager but you are using PerThreadLifetimeManager (which is said to be buggy anyways) in your code. May that be the cause of your problems?
Ok, I refactored the solution to do much more explicit Resolve calls instead of .ctor injection and then after all that I realized the main issue was around trying to update an object while iterating over an IQueryable that contained it.
Much ado about nothing, seems to me.
Thanks for the help.