11

There are a number of issues in your code. Naming. Methods should use verb phrases to denote the action they perform and try to be specific. So your DateList method should become something like GetWorkingDates, or just GetDates if kind of dates is obvious in your case. Test naming. Do spend some time on composing a name for your unit test method that ...


11

I leaked Entity Framework into my domain services, because [...] Fail. The only reason you would ever want to wrap EF with your own repository+unit-of-work implementation, would be to make an interface between EF and your code, possibly to enable swapping EF for something else at one point or another. By leaking it, you defeat the entire purpose of the ...


5

The following code should tell a story as it is reviewed. There are not many comments as the code has been simplified to be easy to understand as it speaks for itself. I suggest comparing it to what you had before and observe the difference in strategy taken to achieve the factory pattern with DI. Apart from the composition root, note the separation of ...


5

What we are looking at is a long tutorial on Inversion of Control and dependency injection. Basically at the most simpilest form you will be looking to abstract your data layer from you application layer and provide interfaces for your IoC container to deliver to the application. This can get quite confusing however all we have to do is remeber our ...


4

public static class IoCContainer { public static IUnityContainer Container = new UnityContainer(); } I've never used Unity, but this looks quite dangerous to me: your IoC container is accessible from anywhere in the code. Dependency Injection does not play well with anything public static - the IoC container is no exception here. In fact, the IoC ...


4

I agree with t3chb0t's comments, this sounds like a bad idea. You assume too much about what functionality you are going to need and what other containers are like. 1) Some containers require you to release components. 2) Some can (should) be disposed. 3) Some can (should) be configured via configuration files. 4) Some containers can be nested. 5) ...


4

The wrapper is very simple but I'd still change a few things to make it prettier, more reliable and more useful so these are my suggestions. public static IIoCWrapper Instance() I'd turn this method into a readonly property with a lazy backing field: private static readonly Lazy<IIoCWrapper> wrapper = new Lazy<IIoCWrapper>(() => new ...


3

I don't think you get much benefit from using the IDbConnection. What I do is just use connection in my repository and use IoC just for the IRepository. The other problem with your code is that there is nothing disposing your connection. Since it's a console app it might not be a big deal, but typically you want to open a connection, do a bunch of work and ...


3

Your Employee class is a ViewModel, concerned with your application's business-level logic: it's much more than a DTO/POCO class, and using it as such sounds very much like mixing up data and business concerns. That said... OnPropertyChanged("Surname"); I'm surprised of seeing literal strings in C# 6.0 code, when nameof is available to make your code ...


3

You're doing it wrong. You can't do Dependency Injection and have static class dependencies scattered throughout your code: when you do Dependency Injection, you need to go all the way or not at all, else you gain the complexity and lose the benefits. Proper DI goes like this: Register: Set up your IoC container and register dependencies. Resolve: Resolve ...


3

I think you might have a performance problem with CreateOrGetLazyType. Obviously, I'm not talking about the IL generation, we know that's not particularly fast. I'm talking about the lock statement. While I'm building a type, no one can grab a lazy type from the dictionary. That might become as problem as the IL generation is, as said above, kinda slow. I'...


2

CreateOrGetLazyType<TLazy, TInterface> This var @container = typeof (IUnityContainer); var @lazy = typeof (TLazy); var @func = typeof (Func<IUnityContainer, TInterface>); name = name ?? @lazy.Name + "Impl"; name = @lazy.Namespace + "." + name; won't be needed if (!@interface.IsInterface) so better do this check earlier. Furthermore ...


1

I think you can make it nice and clean(er) like this: Define an IConnection interface that you pass to the repository: public interface IConnection : IDisposable { IDbConnection Connection { get; } } From this interface you can derive all your connections. There you can have a default constructor to create default connections or a parameterized if you ...


Only top voted, non community-wiki answers of a minimum length are eligible