Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

Hot answers tagged

10

Your question isn't crystal-clear about what it is exactly that your code is supposed to be doing. We have to infer the functionality from this block of code: public void Start() { List<Network> networks = context.Networks.ToList(); foreach (var network in networks) { // create new client...but also // new client gets ...


8

Do I need ninject when implementing DAL with generic repository and unit of work? That's not the question. Inversion of control, repository and unit of work are patterns. Ninject is an IoC container - a tool that resolves dependencies and controls instantiation and object lifetime. You need Ninject (excellent choice, but many other IoC containers are ...


8

Yes, you need a IOC container to maintain your instances. No, your Unit of Work should not create them. With an IOC Container, you centralize the control over the objects and their lifetime. This is extremely powerful. Never should you have an instantiation of unit of work, repositories, ... throughout your application code. You're not the first person ...


7

Here be dragons :P This is a conceptual minefield. I have done this exact thing and can relate, you instinctively want to test a lifecycle. a start-to-finish stub implementation..... but don't. the golden rule of unit testing is never test an interface. test an implementation. I'd add a second rule personally, don't test module interaction. If you ...


7

First: Don't create a base class with a virtual method which simply throws. This moves problem detection from compile time (abstract member not implemented won't compile) to run time (forgotten to override or accidentally called base throws) - usually undesirable. Virtual method says "You can override me if you want but you don't have to". Now your actual ...


6

When you have very "generic" convention, such as these, you need to make sure there's is a way to create a non-convention binding in case you need one. There are several ways to achieve this: provide a way to exclude a type from the convention (for example, you could add a [DoNotBindByConvention] attribute to these types. Not very neat but works.) you ...


6

Regarding your fluent approach to assertions, I'm definitely a fan of anything that makes tests more succinct and readable - as long as it's crystal clear what's going on. A one-liner like "kernel = new StandardKernel()" seems more readable than "GivenIHaveANewKernel()" to me. As a rule of thumb the tests should be very simple without having to resort to a ...


5

Naming conventions. In C#, types are named using PascalCase. Rename: OM_Role to OmRole DAL_Role to DalRole rolesAPIController to RolesApiController and so on The same goes for properties - so tblRoles should be named TblRoles Coding Style You could mark your private field _role readonly. People often also explicitly mark them as private though it's not ...


4

After rethinking the problem, I got another idea. Because it is fundamentally different, I'll post it in a separate answer. The commands are injected to the view model, exposed by properties and bound to the view, right? Why not just setting the commands directly in the view? The following markup extension makes it possible: public class CommandResolver : ...


4

I think the code is definitely much better! I wouldn't worry too much about registering the ICommands in your IoC. After all, you're not going to have hundreds of menu items yet. Anyway, two very minor comments: = beginGroup ?? false; is better as = beginGroup.GetValueOrDefault(); And this: private AxHostConverter() : base("") { } Would be better as: ...


4

This feels a bit awkward: public class CompositionRoot { private static IKernel ninjectKernel; public static void Initialize(INinjectModule module) { ninjectKernel = new StandardKernel(module); } public static T Resolve<T>() { return ninjectKernel.Get<T>(); } public static IEnumerable<T> ...


3

Ninject has a very nice extension called Ninject.Extensions.Factory. It allows you to create factories by specifying an interface. In your case, you could create a factory that creates the commands: public interface ICommandFactory { OpenCommand CreateOpenCommand(); OpenDesignerCommand CreateOpenDesignerCommand(); // ... } Note that ...


3

you could collapse this piece of code into a single line public IDomainTableRepository DomainTables { get { if (_domainTables == null) { _domainTables = new DomainTableRepository(_context); } return _domainTables; } } by using a Null Coalescing operator (??) ...


2

Your code seems like it's primarily plumbing. There are no algorithms or types that could be given the functional treatment. I have only two recommendations. Instead of NinjectWebCommon being abstract/sealed with static members you can make it a module with let-bound functions. _kernel in NinjectResolver is unnecessary because primary constructor ...


2

These four methods contain a lot of duplication: private void ConfigureCodePaneContextMenu() { const int listMembersMenuId = 2529; var parent = _kernel.Get<VBE>().CommandBars["Code Window"].Controls; var beforeIndex = parent.Cast<CommandBarControl>().First(control => control.Id == listMembersMenuId).Index; var items = ...


2

I feel like implementing support for both ICommand and ICommand<T> is going to be really tiresome. Not to mention, that ICommand<T> implementation is going to have two methods: Execute and Execute(T). Which one should I call? Really confusing. If you already know for sure, that you are going to need a command which takes a parameter, you should ...


2

Your implementation looks all right. It should be able to injected by any DI tool as you work with abstractions. But I got couple of improvement notes: Logger type: private static Logger logger = LogManager.GetCurrentClassLogger(); This would generate yournamespace.LoggingService as the logger. I believe key part of your log file is to identify where ...


1

After reading all discussions/answers here I come to this solution. To be clear I just adopted @JanDotNet 's solution for ViewModel. So let's start. First, we don't want to have huge amount of useless command-properties declared. So we need to archive typesafe access from View or ViewModel (As I see there is similar case in Rubberduck) without declaring ...


1

I would typically create a manager for this. Make a class that contains all the properties for each command. Not a factory because we will still allow the DI container to create the commands we just making a nicer way to access them. Now I don't want to keep updating the manager each time a new command is created. Which is why the t4 templates were ...


1

Well I would not recommend doing an abstraction layer over your logging, and also by setting the Logger thru DI, you are not allowing the GetCurrentClassLogger to work the right way. This is HUGELY important because that way you can say that this class X should output the log thru email, and this other class Y can output the log to file. All thru just ...


1

dont use/apply the dependency injection container in class-level unit tests. Instead, do so on component or system level tests. For these, there are other test tools which may be a better fit (xBehave.net, Specflow, Machine.Specifications...) Improve the implementation regarding Separation of Concern / Single responsibility. why does the service itself ...


1

Finally, no need for parameterized Factory.Create method as per this answer: Properly using parameterized Factory.Create() method using DI. In short, because Ninject knows how to resolve your returned type, and also your parameterized types, Ninject shall inject whatever needed to instantiate your class. public class CustomerManagementPresenter : ...


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