Azure Webjob - Per Request Lifetime? - autofac

I have a console app that I'm using for an azure webjob. I need to have a unique nhibernate session per azure webjob request. I'm using autofact to manage DI.
How can I get Per Request Lifetime instancing in azure webjobs? Inherently a console app doesn't have this. Do I need to change project types?
I've seen several answers on how to do something similar here and here. But they basically boil down to passing in a container as a parameter to functions. That's not really instance per request.

As far as I know, the webjob doesn't have the request. It just run programs as background processes on App Service Web Apps. It couldn't get the request.
In my opinion, the Per Request Lifetime instancing is used in web application like ASP.NET web forms and MVC applications not webjobs.
What do you mean of the request?
Normally, we will use the Instance Per Dependency in the webjobs by using AutofacJobActivator.
It will auto create new instance when the function is triggered.
Here is a webjob example:
class Program
{
// Please set the following connection strings in app.config for this WebJob to run:
// AzureWebJobsDashboard and AzureWebJobsStorage
static void Main()
{
var builder = new ContainerBuilder();
builder.Register(c =>
{
var model = new DeltaResponse();
return model;
})
.As<IDropboxApi>()
.SingleInstance();
builder.RegisterType<Functions>().InstancePerDependency();
var Container = builder.Build();
var config = new JobHostConfiguration()
{
JobActivator = new AutofacJobActivator(Container)
};
var host = new JobHost(config);
// The following code ensures that the WebJob will be running continuously
host.RunAndBlock();
}
}
public class AutofacJobActivator : IJobActivator
{
private readonly IContainer _container;
public AutofacJobActivator(IContainer container)
{
_container = container;
}
public T CreateInstance<T>()
{
return _container.Resolve<T>();
}
}
public interface IDropboxApi
{
void GetDelta();
}
public class DeltaResponse : IDropboxApi
{
public Guid id { get; set; }
public DeltaResponse()
{
id = Guid.NewGuid();
}
void IDropboxApi.GetDelta()
{
Console.WriteLine(id);
//throw new NotImplementedException();
}
}
Functions.cs:
public class Functions
{
// This function will get triggered/executed when a new message is written
// on an Azure Queue called queue.
private readonly IDropboxApi _dropboxApi;
public Functions(IDropboxApi dropboxApi)
{
_dropboxApi = dropboxApi;
}
public void ProcessQueueMessage([QueueTrigger("queue")] string message, TextWriter log)
{
log.WriteLine("started");
// Define request parameters.
_dropboxApi.GetDelta();
}
}
When the function triggered, it will auto create new instance.

Related

Using single dbcontext for unit of work in service layer

I trying to implement business layer (service layer) along with repository layer. So my project has following layers EF <--- Repository <--- Service <--- Controller <--- View.
My context class looks like :
public class ToDoContext : DbContext
{
public ToDoContext()
: base("ToDoContext")
{
}
public virtual DbSet<Project> Projects { get; set; }
public virtual DbSet <Collaborator> Collaborators { get; set; }
public virtual DbSet<ActionTask> Tasks { get; set; }
}
My ProjectRepository looks like :
public class ProjectRepository : IProjectRepository, IDisposable
{
ToDoContext Context;
public ProjectRepository(ToDoContext context)
{
this.Context = context;
}
public virtual List<Project> AllProjects()
{
IQueryable<Project> projects = Context.Projects;
return projects.ToList<Project>();
}
public Project Find(int? id)
{
// some code
}
public void InsertOrUpdate(Project project)
{
// some code
}
public void Delete(int? id)
{
// some code
}
public void Save()
{
// some code
}
public void Dispose()
{
Context.Dispose();
}
}
My ProjectService class looks like :
public class ProjectService : IProjectService
{
IProjectRepository ProjectRepo;
ICollaboratorRepository CollaboratorRepo;
public ProjectService(IProjectRepository projectRepo, ICollaboratorRepository collaboratorRepo)
{
this.ProjectRepo = projectRepo;
this.CollaboratorRepo = collaboratorRepo;
}
public List<Project> GetAllProjects()
{
return ProjectRepo.AllProjects();
}
public void CreateProject(FormCollection formData)
{
// code to parse form data as per my business needs
// code to code to fetch related collaborator list
// save the project data
}
public List<Collaborator> GetCollaborators(string[] collaboratorId)
{
// Fetch collaborator list using collaborator repository
return CollaboratorRepository.GetAllCollaborators();
}
}
Similarly I have implemented service and repository layer for my collaborator.
To summarize the code my CreateProject() method in ProjectService class fetches collaborator list using collaborator repository and create a new project attaching the collaborator list with this newly created project and save it.So i guess for me this whole process is One Unit Of Work.
When I fetch list of collaborators using CollaboratorRepository and try to save the newly created project using ProjectRepository, it throws me error "An entity object cannot be referenced by multiple instances of IEntityChangeTracker.". I guess this is because CollaboratorRepository dbcontext is not disposed yet. So I am manually disposing each context before using new context. I know I can't afford this overhead of manually disposing the context. Can anyone help me please?
I know I should be using same dbcontext object for one unit of work. But i don't know how to achieve this when dbcontext object is exposed to repository rather than service layer.
How is the IoC configured? You should register the LifeTime of the DbContext per Request\Thread, in order to get the same instance per business transaction.
Tips: In order to have a reusable Service outside of a web enviroment, do not pass the FormCollection to the CreateProject method. The parsing of the FormCollection should be done by the controller\model binder.
For Ninject, try InRequestScope
kernel.Bind<ToDoContext>().To<ToDoContext>().InRequestScope();

Shim DbContext ctor for Effort unit testing

I'd like to intercept var context = new MyDbContext() to return a different constructor call instead.
The great thing about EFfort is that it let's you set up an easy in-memory database for unit testing.
var connection = Effort.DbConnectionFactory.CreateTransient();
var testContext = new MyDbContext(connection);
But then you'd have to inject that context into your repository.
public FooRepository(MyDbContext context) { _context = context; }
Is it possible to just intercept var context = new MyDbContext() , so that it returns the testContext?
using (var context = new MyDbContext()) {
// this way, my code isn't polluted with a ctor just for testing
}
You have two possible options. Using factories or via Aspect oriented programming (like PostSharp)
referencing this article: http://www.progware.org/Blog/post/Interception-and-Interceptors-in-C-(Aspect-oriented-programming).aspx
Using PostSharp (AOP)
PostSharp is a great tool and can achieve the most clean interception
possible (meaning no changes in your classes and object generation at
all even if you do not your factories for object creation and/or
interfaces) but it is not a free library. Rather than creating proxies
at runtime, it injects code at compile time and therefore changes your
initial program in a seamless way to add method interception.
.....
The cool thing in this is that you do not change anything else in your
code, so your object can be still generated using the new keyword.
Using DI and Factory-pattern
I personally prefer the factory-pattern approach, but you seem apposed to having to inject any dependencies into your classes.
public interface IDbContextFactory<T> where T : DbContext {
T Create();
}
public class TestDbContextFactory : IDbContextFactory<MyDbContext> {
public MyDbContext Create() {
var connection = Effort.DbConnectionFactory.CreateTransient();
var testContext = new MyDbContext(connection);
return testContext;
}
}
public class FooRepository {
MyDbContext _context;
public FooRepository(IDbContextFactory<MyDbContext> factory) {
_context = factory.Create();
}
}
(edit: I just realized this isn't actually returning the other ctor call. working on it.)
Figured it out. Simple enough if you know how to do it:
[TestMethod]
public void Should_have_a_name_like_this()
{
// Arrange
var connection = Effort.DbConnectionFactory.CreateTransient();
ShimSolrDbContext.Constructor = context => new SolrDbContext(connection);
// Act
// Assert
}
And as usual, EFfort requires this constructor in the DbContext class:
public class SomeDbContext
{
public SomeDbContext() : base("name=Prod")
{
}
// EFfort unit testing ctor
public SomeDbContext(DbConnection connection) : base(connection, contextOwnsConnection: true) {
Database.SetInitializer<SolrDbContext>(null);
}
}
But it means the repo is blissfully unaware of the special Transient connection:
public class SomeRepository
{
public void SomeMethodName()
{
using (var context = new SomeDbContext())
{
// self-contained in repository, no special params
// and still calls the special test constructor
}
}
}

Visual Studio Online Unit Test and localDb

I have a solution that is built on Visual Studio Online.
All the unit tests in this solution require a database, I tried to get the build use a test's dedicated localdb (by adding a light mdf file in the test project and use a localdb connection string) but it fail with this error (everything work fine on my desktop) :
System.Data.SqlClient.SqlException: Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=29460; handshake=161; ---> System.ComponentModel.Win32Exception: The wait operation timed out.
EDIT
The connection string is
<add name="TestDb" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=AeroBase;Integrated Security=true;AttachDBFilename=|DataDirectory|\App_Data\AeroBase.mdf" providerName="System.Data.SqlClient" />
I use EF6 code first, repository and unit of work patterns to access it.
Here is the DbContext :
public class AeroDataContext : DbContext, IDbContext
{
private Guid DataContextId;
private string _name;
public string Name { get { return _name; } }
public AeroDataContext(string cnxStringName, string cnxString)
: base(cnxString)
{
this.Database.Log = delegate(String name)
{
// Debug.WriteLine(name);
};
_name = cnxStringName;
this.Configuration.LazyLoadingEnabled = false;
DataContextId = Guid.NewGuid();
Debug.WriteLine("AeroDbCreation Id = " + DataContextId.ToString());
}
}
The DbContext is instanciated using a unitOfWorkScope :
public class UnitOfWorkFactory : IUnitOfWorkFactory
{
private string _cnxStringName;
private string _cnxString;
public UnitOfWorkFactory(string cnxStringName, string cnxString)
{
_cnxString = cnxString;
_cnxStringName = cnxStringName;
}
public IUnitOfWorkScope GetUnitOfWorkScope(bool disposeAtEndOfContext = true)
{
return new UnitOfWorkScope(new AeroDataContext(_cnxStringName, _cnxString), disposeAtEndOfContext);
}
}
which allows me to do things like this in the test (and in the app)
[TestMethod]
public void DB_Get_LFFE_Airport_By_ICAOInclude_SubType()
{
//structuremap container built in the TestInitilized method
IUnitOfWorkFactory _uowf = container.GetInstance<IUnitOfWorkFactory>();
using (IUnitOfWorkScope uows = _uowf.GetUnitOfWorkScope(true))
{
IAirportRepository repo = uows.GetRepository<IAirportRepository>();
Airport ar = repo.SearchByICAO("LFFE").FirstOrDefault();
AirportValidator.LFFE(ar);
}
}
Is this scenario even possible? is there any other way to do that?
This very likely has to do with LocalDb not being initialized on the VSO build server that gets spun up to run the build.
According to https://github.com/ritterim/automation-sql, LocalDb may be installed, but not initialized.
LocalDB installed but can't Connect
You may have LocalDB installed, but never initialized the instance on
your machine. Run this command via command prompt.
LocalDB SQL EXPRESS 2014
"C:\Program Files\Microsoft SQL Server\120\Tools\Binn\SqlLocalDB.exe"
create "v12.0" 12.0 -s LocalDB SQL Express 2012
"C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SqlLocalDB.exe"
create "v11.0" 11.0 -s Verify that the command worked by using SQL
Server Management Studio to connect to the instance.
My solution:
Every time VSO launches a build, it creates a brand new virtual machine from a template to run the build. In my case, I wanted to create a small LocalDb database dynamically in order to run unit tests against.
I'm using the RimDev.Automation.Sql nuget package (http://www.nuget.org/packages/RimDev.Automation.Sql/) to allow my tests to programmatically create the database.
I also wanted to integrate with Unity and Entity Framework 6 so that it mimics my database access in production as closely as possible. To do this, I created a based class that all of my tests inherit from. One thing that I wanted is for all of my tests to share the same database, so I made the LocalDb creation static.
In addition, the initialization runs a set of scripts in the Resources folder in order to pre-populate the database with stock data if you so wish. You'll need to make sure that the sql scripts are marked to copy to the output folder (see the properties) so that the files will be in the proper path when the unit test is running.
If you want to create a new database per test class or even per test, this could easily be changed.
using System;
using System.Data.Entity;
using System.IO;
using Microsoft.Practices.Unity;
using Playground.Model;
using RimDev.Automation.Sql;
namespace Playground.UnitTests
{
public abstract class TestBaseClass
{
// For now, these are static. We may want to change them at some point
// to be per class so we create separate databases for each class run, but
// for now, let's not do that for speed sake.
private static readonly IUnityContainer _container = new UnityContainer();
private static bool _isRegistered = false;
private static readonly object _syncRoot = new object();
private static LocalDb LocalDb = new LocalDb(databaseName: "PlaygroundTestDb", databasePrefix: "pg", version: "v12.0");
private static bool _isInitialized = false;
protected TestBaseClass()
{
RegisterComponents(_container);
InitializeData();
_container.BuildUp(GetType(), this);
}
private void InitializeData()
{
lock (_syncRoot)
{
if (!_isInitialized)
{
var dbContext = _container.Resolve<PlaygroundEntities>();
Database.SetInitializer(
new MigrateDatabaseToLatestVersion<PlaygroundEntities, Playground.Model.Migrations.Configuration>());
// Make sure database exists.
dbContext.Database.Initialize(true);
foreach (
var f in Directory.GetFiles(Path.Combine(Environment.CurrentDirectory, "Resources"), "*.sql"))
{
dbContext.Database.ExecuteSqlCommand(File.ReadAllText(f));
}
}
_isInitialized = true;
}
}
private void RegisterComponents(IUnityContainer container)
{
lock (_syncRoot)
{
if (!_isRegistered)
{
// WARNING! Most methods in the unity container are not thread safe. See http://unity.codeplex.com/discussions/27496
// We may need to expose protected methods to register certain types. For now, assume all of the
// tests use the same injected objects. If a test REALLY needs to a different dependency, the test can
// manually create it as well.
container.RegisterType<PlaygroundEntities, PlaygroundEntitiesTest>(new TransientLifetimeManager(),
new InjectionConstructor(new object[] {LocalDb.ConnectionString}));
}
_isRegistered = true;
}
}
}
}
Here is a sample test:
using System.Linq;
using Microsoft.Practices.Unity;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Playground.Model;
namespace Playground.UnitTests
{
[TestClass]
public class UnitTest1 : TestBaseClass
{
[Dependency]
public PlaygroundEntities Db { get; set; }
private static bool _initialized = false;
[TestInitialize]
public void TestInitialize()
{
if (!_initialized)
{
Db.Playgrounds.Add(new Playground.Model.Playground() {Name = "Dave's playground", Location = "SomeTown"});
Db.SaveChanges();
_initialized = true;
}
}
[TestMethod]
public void TestMethod1()
{
var p = Db.Playgrounds.FirstOrDefault(pg => pg.Name == "Dave's playground");
Assert.IsNotNull(p);
}
[TestMethod]
public void TestMethod2()
{
var p = Db.Playgrounds.FirstOrDefault(pg => pg.Location == "SomeTown");
Assert.IsNotNull(p);
}
}
}
Lastly, in my test project, I have the test entities object.
using Playground.Model;
namespace Playground.UnitTests
{
public class PlaygroundEntitiesTest : PlaygroundEntities
{
private PlaygroundEntitiesTest()
{
}
public PlaygroundEntitiesTest(string connectionString) : base(connectionString)
{
}
}
}
In my models project, I have my entity and my context.
Playground.cs
using System;
namespace Playground.Model
{
public class Playground
{
public Guid Id { get; set; }
public string Name { get; set; }
public string Location { get; set; }
}
}
PlaygroundEntities.cs
using System.Data.Entity;
namespace Playground.Model
{
public class PlaygroundEntities : DbContext
{
public PlaygroundEntities() : base("PlaygroundConnectionString")
{
}
public PlaygroundEntities(string connectionString) : base(connectionString)
{
}
public virtual DbSet<Playground> Playgrounds { get; set; }
}
}
Lastly, I set up a post-build step in the unit test project to execute the command to initialize LocalDb as follows:
The full command is
"C:\Program Files\Microsoft SQL Server\120\Tools\Binn\SqlLocalDB.exe"
create "v12.0" 12.0 -s
Then, it was as simple as pushing to Visual Studio Online and launching my build.

How to structure unitofwork / service layer / repository, so that they work with DI (Unity) and Moq for Unit Testing

I have an MVC app (EF6, SQL Server CE 4), that I recently refactored to add a UnitOfWork class and a service layer (so that I could utilise a single DbContext per request, and conduct transactions successfully).
Previously, I was using Unity to inject the repositories into the controller. My unit tests (for the controllers) were simple to setup - I just mocked each repository, and passed those into the controller constructor.
After refactoring, I now use Unity to inject the Service Layer (to the controller) and UnitOfWork (into the Service Layer). The Service Layer now instantiates each repository, by passing the UnitOfWork.DbContext to the repository's constructor.
In my Unit Tests, I am attempting to mock the UnitOfWork, and the ServiceLayer (and pass the mocked UnitOfWork object into the ServiceLayer's constructor). However, the tests fail, saying "TestFixtureSetup failed in ControllerTest".
I assume it's due to how I'm attempting to pass the UnitOfWork mock into the ServiceLayer mock, so would appreciate any guidance on how to do this correctly.
Relevant code snippets below.
UnitOfWork
public interface IUnitOfWork:IDisposable
{
void Save();
IDSMContext Context { get; }
}
public class UnitOfWork : IUnitOfWork, IDisposable
{
private IDSMContext _context;
public UnitOfWork()
{
_context = new IDSMContext();
}
public IDSMContext Context
{
get {return _context;}
}
public void Save()
{
_context.SaveChanges();
}
private bool disposed = false;
protected virtual void Dispose(bool disposing)
{
if (!this.disposed)
{
if (disposing)
{
_context.Dispose();
}
}
this.disposed = true;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
Service Layer
public interface IService
{
// Repositories
IUserRepository Users { get; }
IUserTeamRepository UserTeams { get; }
IPlayerRepository Players { get; }
IGameRepository Games { get; }
IUserTeam_PlayerRepository UserTeamPlayers { get; }
void Save();
}
public class Service: IService, IDisposable
{
private IUnitOfWork _unitOfWork;
private IUserRepository _userRepository;
private IUserTeamRepository _userTeamRepository;
private IPlayerRepository _playerRepository;
private IGameRepository _gameRepository;
private IUserTeam_PlayerRepository _userTeamPlayerRepository;
public Service(IUnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
initialiseRepos();
}
private void initialiseRepos(){
_userRepository = _userRepository ?? new UserRepository(_unitOfWork.Context);
_userTeamRepository = _userTeamRepository ?? new UserTeamRepository(_unitOfWork.Context);
_playerRepository = _playerRepository ?? new PlayerRepository(_unitOfWork.Context);
_gameRepository = _gameRepository ?? new GameRepository(_unitOfWork.Context);
_userTeamPlayerRepository = _userTeamPlayerRepository ?? new UserTeam_PlayerRepository(_unitOfWork.Context);
}
public IUserRepository Users { get { return _userRepository; } }
public IUserTeamRepository UserTeams { get { return _userTeamRepository; } }
public IPlayerRepository Players { get { return _playerRepository; } }
public IGameRepository Games { get { return _gameRepository; } }
public IUserTeam_PlayerRepository UserTeamPlayers { get { return _userTeamPlayerRepository; } }
public void Save()
{
_unitOfWork.Save();
}
Unity Container Instance Setup
Instance.RegisterType<IService, Service>(new PerThreadLifetimeManager())
.RegisterType<IUnitOfWork, UnitOfWork>();
Controller Constructor
public GameController(IService service)
{
_service = service;
}
Test Constructor
_mockUnitOfWork = new Mock<IUnitOfWork>();
_mockServiceLayer = new Mock<IService>(_mockUnitOfWork.Object); //this line fails
Test Controller Method
GameController Controller = new GameController(_mockServiceLayer.Object);
If you want to test methods of GameController you just need to mock/stub the dependencies of that class. Just do this:
_mockServiceLayer = new Mock<IService>();
_controller = new GameController(_mockServiceLayer.Object);
When you are testing the Controller, you shouldn't worry about the dependencies of the service. UnitOfWork is never exposed outside your service, so don't worry about it when testing the controller. On your tests you may now setup expectations of methods called on your service, like verifying that Save was called once (If you were testing the service, then you would worry about the IService.Save calling Save on a mock of the IUnitOfWork!):
_mockServiceLayer.Verify(s=> s.Save(), Times.Once());
The problem you will find is that your service class is not abstracting the controller from the repositories, as your controller will get the repositories via the properties in IService and query directly the repositories. So if you want to test your controller methods, you will still need to mock the repositories, doing something like:
//Initialization before each test:
_mockUserRepo = new Mock<IUserRepository>();
//...other repositories
_mockServiceLayer = new Mock<IService>();
_mockServiceLayer.Setup(s => s.Users).Returns(_mockUserRepo.Object);
//... setup properties in IService for other repositories
_controller = new GameController(_mockServiceLayer.Object);
//In some test:
var user = new User();
_mockUserRepo.Setup(s => s.Get(123)).Returns(user);
call some controller method and make sure returned model is "user"
This way you may find yourself configuring the expectations and data returned by a few repositories and the UnityOfWork, just for testing the methods in the Controller! Not to mention that your Controller class effectively depends on your repositories, not just on the service.
Another approach would be if your service class contains higher level methods like GetUser, CreateUser or AddUserToTeam (likely having multiple services with closely related methods). The service would then shield the controller from retrieving/sending data to the repositories and using the UnitOfWork.
That way in your tests you would only need to mock IService.
For example a test for a typical "GET" action may look like:
//Arrange
var user = new User();
_mockServiceLayer.Setup(s => s.GetUser(123)).Returns(user);
//Act
var viewResult = _controller.GetUser(123) as ViewResult;
//Assert
Assert.AreEqual(user, viewResult.Model);
Hopefully this will help clarifying things a bit!
In the line that fails you are mocking the IService which does not have a constructor, so passing it args will cause it to fail. Since you are only trying to unit test the controller, you should change the line to this:
_mockServiceLayer = new Mock<IService>();
and then specify the the behaviors you want using _mockServiceLayer.Setup(...). Remember your interface doesn't know anything about your unit of work so you do not need to mock the unit of work.
If you actually want to test the controller and service layer together then you would do something like this:
_mockUnitOfWork = new Mock<IUnitOfWork>();
var serviceLayer = new Service(_mockUnitOfWork.Object);
var controller = new GameController(serviceLayer);
You would probably be better off unit testing the controllers and the serviceLayer separately, each time mocking the layer below.

Service Class + Instantiating new classes

I wanted to know if this was thread safe/ good practice. My IOC is ninject, everything service layer call is via the default setting (In transient scope I think?).
Question, is instantiating new FileAllocation(loggedonuser,_repo) correct? The best way? What is the best way to do this? This is a domain class that holds logic that could be called from various services, there are usually a few database calls involved, most of the time no persistance is necessary...
Anyway, I call my service method via an interface e.g.
void SaveFile(int reportid, stream file); //Interface name: IReportFileService
public Class FileService: Servicebase, IReportFileService
{
private readonly IRepoSession _repo;
public FileService(IUserSession user, IRepoSession repo, IUpdateSession update)
: base(user,update)
{
_repo = repo;
}
//save file if users 'counter' is ok..
public void SaveFile(int reportid, stream file)
{
//here I want to instantiate a new class that I store in my domain and store the counters
//etc and do related db calls to check up relevant values
//note loggedonuser is a prop on my *base class*
var userChecks = new FileAllocation(loggedonuser,_repo);
userChecks.CountEmUp(); //exception is thrown if 0, less than "limit" etc...
base.update(userChecks.mycompany); //persist
base.commit(); //base class method includes try, catch block...
}
}
public class FileAllocation
{
private readonly IRepoSession _repo;
private readonly Loggedonuser _user;
private int CompanyUploads;
private int UserUploads;
public Company mycompany;
public FileAllocation(Loggedonuser user, IRepoSession repo)
{
_repo = repo;
_user = user;
}
public void CountEmUp()
{
//do error checking,
//load up other tables can user upload - permissions, count is ok etc...
// check the upload type if of certain type we cannot proceed - call another method on this class
//set myCompany variable to new limits etc...
}
}
Base Service includes a prop, I dont want to instantiate this from other services i.e. more that once, how do I avoid that?
private LoggedonuserDTO _currentuser = null;
protected LoggedonuserDTO loggedonuser
{
get
{
if (_currentuser == null)
{
_currentuser = _user.GetCurrentUser(); //make db call here...
}
return _currentuser;
}
}
#Darin suggested:
public interface IFileAllocation
{
CountEmUp(Loggedonuser currentuser);
}
//pass in loggedonuser to any method that requires it...
public class FileAllocation: IFileAllocation
{
CountEmUp(Loggedonuser currentuser)
{
//do whatever here...
}
}
var userChecks = new FileAllocation(loggedonuser,_repo);
introduces a strong coupling between the FileService and the FileAllocation classes. If this is not a problem for you then you can leave it that way. Otherwise you could abstract the operations of this FileAllocation class into an interface and then inject it into FileService. This way the FileService is weakly coupled with FileAllocation and could be reused in different contexts and unit tested in isolation.