I have an application that I am working on. The call to the data manager to set up looks like this:
public partial class App : Application
{
public App()
{
InitializeComponent();
MainPage = new Japanese.MainPage();
}
public static DataManager DB
{
get
{
if (AS.dm == null)
{
AS.dm = new DataManager();
}
return AS.dm;
}
}
protected override void OnStart()
{
AS.GetSettings();
AS.selectedPhraseCount = AS.dm.GetTotalPhrasesCountForSelectedCategories();
}
In other words the datamanager is set up when it's first needed.
Can someone tell me if there is any advantage to doing this. It would seem to me to be simpler just to do a call to AS.dm = new DataManager() in the onStart event.
public partial class DataManager
{
protected static object locker = new object();
protected SQLiteConnection db1;
protected SQLiteConnection db2;
public DataManager()
{
db1 = DependencyService.Get<ISQLiteDB1>().GetConnection();
db2 = DependencyService.Get<ISQLiteDB2>().GetConnection();
You'd need to post a bit more code (for example where are dm and AS declared?) to be absolutely sure, but this method of having a static declaration with a private constructor is called the Singleton pattern and is designed to ensure that only one instance of the object (in your case the DataManager) can ever exist.
See this existing question
However, your code looks slightly odd in the OnStart because it looks like you are referencing the datamanager using the dm backing variable rather than the DM property.
Related
In our project we are using aspnetzero template. This template allows a simple but abstracted usage of hangfire. Now we would like to add Hangfire.Console to our project which would allow us to write logs to hangfires dashboard.
In order to write a log statement to the dashboard console we have to access the PerformContext of the current running job. Unfortunately because of the abstraction in aspnetzero we can't inject the PerformContext as it would be planned by hangfire. What we do have access to is the hangfire namespace and all it's static objects.
Therefore my question: Is there a way to get the PerformContext by another way than passing null to the execution method?
What I have tried so far:
By using the IServerFilter interface a method OnPerforming should be called. But unfortunately this is not the case within aspnetzero background jobs.
I tried to overwrite/extend the given base class BackgroundJob< T > of aspnetzero but with no luck. Perhaps someone can give me a hint in this direction.
I used JobFilterAttribute with a IServerFilter.
Example:
[AttributeUsage(AttributeTargets.Class)]
public class HangFirePerformContextAttribute : JobFilterAttribute, IServerFilter
{
private static PerformContext _Context;
public static PerformContext PerformContext
{
get
{
return new PerformContext(_Context);
}
}
public void OnPerformed(PerformedContext filterContext)
{
Context = (PerformContext)filterContext;
_Context = Context;
}
public void OnPerforming(PerformingContext filterContext)
{
Context = (PerformContext)filterContext;
_Context = Context;
}
}
And I create a new Class AsyncBackgroundJobHangFire<TArgs> : AsyncBackgroundJob<TArgs>
Exemple:
[HangFirePerformContext]
public abstract class AsyncBackgroundJobHangFire<TArgs> : AsyncBackgroundJob<TArgs>
{
public PerformContext Context { get; set; }
protected async override Task ExecuteAsync(TArgs args)
{
Context = HangFirePerformContextAttribute.PerformContext;
await ExecuteAsync(args, Context);
}
protected abstract Task ExecuteAsync(TArgs args, PerformContext context);
}
It´s Work
In a Class of job i use a AsyncBackgroundJobHangFire
And de method is
[UnitOfWork]
protected override async Task ExecuteAsync(string args, PerformContext context)
{
}
I have suffered using abp's implementation of hangfire jobs as well. I don't know how to answer your question precisely, but I was able to access a PerformingContext by implementing an attribute that extends JobFilterAttribute and implements IClientFilter, IServerFilter, IElectStateFilter, IApplyStateFilter. The interfaces will depend on your requirements, but I was capable of accessing PerformingContext this way.
You should never use a static field for that, even if marked with a ThreadStaticAttribute , please refer to this link for more details
https://discuss.hangfire.io/t/use-hangfire-job-id-in-the-code/2621/2
I have an application that uses a static class to store settings:
namespace ABC
{
public static class MS
{
public static bool abc;
public static bool def;
...
}
}
When the app starts up it goes to the database and updates some of these settings.
I have been told that holding them in a static class is not ideal for when I am doing bindings and adding notification so I'm thinking I should new a class and the hold them in an instance. If that's the case can someone give me some advice. Should I do that when the application starts up and should it be in the constructor of the App() if that is the best way to do it then how can I do this. Any small 4-5 line example would be a big help
public partial class App : Application
{
public static xxx
public App()
{
AS.appUpdated = "Feb 1, 2017";
AS.appVersion = "0.1";
InitializeComponent();
MainPage = new MS.MainPage();
}
}
Have a look at James Montemagno's settings plugin.
https://github.com/jamesmontemagno/SettingsPlugin
This abstracts away a lot of the plumbing around settings and persisting them locally. Calling one of your settings from anywhere in your application then becomes as simple as calling Settings.MySettingName.
When it comes to binding these values to a view I would always create a property for them in your view model that simply returns the value from the settings. If need be you can put them in a base viewmodel and go from there.
public class MyViewModel : BaseViewModel
{
}
public class BaseViewModel
{
public bool SettingA => Settings.SettingA;
public bool SettingB => Settings.SettingB;
}
I've been trying to implement a new MVC3 project with Entity Framework 4.1, which instantiates the dbContext on Application_BeginRequest, and disposes it on Application_EndRequest
protected virtual void Application_BeginRequest()
{
HttpContext.Current.Items["_EntityContext"] = new EntityContext();
}
protected virtual void Application_EndRequest()
{
var entityContext = HttpContext.Current.Items["_EntityContext"] as EntityContext;
if (entityContext != null)
entityContext.Dispose();
}
The EntityContext class is defined as follows:
public class EntityContext : MyEntities, IDisposable
{
**//should this be static?**
public static EntityContext Current
{
get { return HttpContext.Current.Items["_EntityContext"] as EntityContext; }
}
void IDisposable.Dispose()
{
Current.Dispose();
}
My question is, will defining my Current property as static cause any problems in a multi-user scenario?
Your lifespan on DbContext is WAY too long. You should be spinning up a bare minimum of one per request, and even better one per access to the database.
As insta pointed out, you should instance the context when you actually need it. There's no advantage making your context lifespan that long.
As a side-note, there's no need to call explicitly the Dispose method, since the .NET Garbage Collector will do that more efficiently for you.
You could instance the context per class, since you're using MVC, instance the context once per Controller.
public class MyTableObjectController : Controller
{
MyContext context = new MyContext();
public ActionResult Index()
{
var model = context.MyTableObjects;
return View(model);
}
}
I might ask, why are you trying to keep your context available between Begin and End request? Are you trying to avoid instancing it?
I need help converting the following class for use in a program that I am developing. The original was a demo program from IdeaBlade called "PRISM EXPLORER" based on Unity. I need help converting one part from UNITY to MEF. I handled everything else. Just stuck on this one. I already marked my classes with the MEF "[EXPORT(typeof(XXX))]" and I think I need to use the "ComposeExportedValue" somehow. The confusing part is finding the equivelant for this line:
var provider =
(IEntityManagerProvider) _container.Resolve<IPersistenceGateway>();
_container.RegisterInstance<IEntityManagerProvider>(provider);
THANKS!
The following is the entire class I need to convert. You can find the original here: Ideablade PRISM Page
using Microsoft.Practices.Composite.Modularity;
using Microsoft.Practices.Composite.Regions;
using Microsoft.Practices.Unity;
using PrismExplorer.Infrastructure;
namespace ModelExplorer.Explorer {
public class ExplorerModule : IModule {
private readonly IUnityContainer _container;
public ExplorerModule(IUnityContainer container) {
_container = container;
}
public void Initialize() {
InitializeContainer();
SetViews();
}
// ToDo: Consider getting from configuration
private void InitializeContainer() {
RegisterGatewayAndEntityManagerProvider();
_container.RegisterType<IQueryRepository, QueryRepository>(
new ContainerControlledLifetimeManager()); // singleton
}
private void RegisterGatewayAndEntityManagerProvider() {
_container.RegisterType<IPersistenceGateway, PrismExplorerPersistenceGateway>(
new ContainerControlledLifetimeManager()); // singleton
var provider =
(IEntityManagerProvider) _container.Resolve<IPersistenceGateway>();
_container.RegisterInstance<IEntityManagerProvider>(provider);
}
private void SetViews() {
var regionManager = _container.Resolve<IRegionManager>();
var view = _container.Resolve<ExplorerView>();
regionManager.AddToRegion(RegionNames.MainRegion, view);
regionManager.RegisterViewWithRegion(RegionNames.MainRegion, typeof(ExplorerView));
}
// Destructor strictly to demonstrate when module is GC'd
//~MevModule() {
// System.Console.WriteLine("Goodbye, MevModule");
//}
}
}
The two corresponding methods on a CompositionContainer are ComposeExportedValue<T>(...), which allows you to add a specific instance to the container, and GetExportedValue<T>(...) which gets an instance of T from the container.
If you can design your types in a way to reduce this use of service location and try and prefer constructor injection, it will make your code much easier to maintain and test. E.g., could your code be transformed into:
[Export(typeof(IModule))]
public class ExplorerModule : IModule
{
[ImportingConstructor]
public ExplorerModule(IPersistenceGateway gateway)
{
}
}
I am using Ninject and the MVC3 extension installed with nuget. My kernel setup code is in the App_Start/NinjectMVC3.cs file. Everything works great in controllers, but I can't figure out how to (properly) bind interfaces in the Global.asax.cs MvcApplication code.
I ended up using a hack (creating a public NinjectMVC3.GetKernel() method that returns bootstrap.kernel). However, that will be deprecated, and there must be a proper way to do this that I am not seeing.
Here is my code:
public class LogFilterAttribute : ActionFilterAttribute
{
private IReportingService ReportingService { get; set; }
public LogFilterAttribute( IReportingService reportingService )
{
this.ReportingService = reportingService;
}
...
}
public class MvcApplication : System.Web.HttpApplication
{
public static void RegisterGlobalFilters( GlobalFilterCollection filters )
{
filters.Add( new HandleErrorAttribute() );
filters.Add( new LogFilterAttribute() );
}
...
protected void Application_Start()
{
...
RegisterGlobalFilters( GlobalFilters.Filters );
// NOTE hack:
var kernel = NinjectMVC3.GetKernel();
var logger = kernel.Get<ILogger>();
var bw = new BackgroundWork(logger);
Application["BackgroundWork"] = bw;
bw.Start();
}
}
There are two interfaces I am interested in. The first is just binding an object to a Global variable (the ILogger for the BackgroundWork).
And the second is for an ActionFilter. I read http://www.planetgeek.ch/2010/11/13/official-ninject-mvc-extension-gets-support-for-mvc3/, but I don't see how it plugs into the actual registration (filter.Add).
I don't want to use the Property Inject if I can avoid it.
Any thoughts on the proper way to do this?
Thanks
MVC 3 introduces the DependencyResolver which is populated into a singleton, and the Ninject extension supports it. You could use that in your MvcApplication class if you need it:
protected void Application_Start()
{
// ...
var logger = DependencyResolver.Current.GetService<ILogger>();
}
Now I should point out that it is unnecessary to do this with action filters. In Ninject.MVC3 you are supposed to use the BindFilter syntax, like so:
// Declare empty attribute
public class MyFilterAttribute : FilterAttribute { }
// Dependency module
public class MyModule : NinjectModule
{
public override void Load()
{
// Other bindings
// ...
this.BindFilter<MyActionFilter>(FilterScope.Action, 1)
.WhenControllerHas<MyFilterAttribute>();
}
}
Note that you have to use this because BindFilter is an extension method, and you also have to reference the Ninject.Web.Mvc.FilterBindingSyntax namespace.