New answers tagged

0

I post here my currents thought about that problem. So after I started implementing own IDatabaseTransaction I realize that root of the problem not in the transaction, but in the fact that my database layer still contains some business logic(generate some default values while inserting new rows). So my new decision was create and generate all needed data ...


1

You want to create a user control. You can predefine the layout, much like you would with a Form, and then create and add a new instance of the control to a Form, just like you'd dynamically add a new label, text box, etc.


0

I've seen it done with tabs after commas before so you get. {Reports.ReallyLongFoo, New ReportMetadata("Really Long Foo Report", PaperSize.A4, 8, 12, ...)}, {Reports.ShorterBar, New ReportMetadata("Shorter Bar Report", PaperSize.A4, 8, 14, ...)}, Unfortunately it fights against any automated formatting of the code block.


0

I like the idea of XML for simple things like this. If you restructure the XML the readability goes up. Something like this. Dim ReportConfigurations As XElement = <Reports> <Report> <name>Foo Report</name> <papaersize>A4</papaersize> <fontsize&...


1

The source to the method is now online: http://referencesource.microsoft.com/#mscorlib/system/string.cs


1

I think the solution you have is the right one. If the report metadata is declared in one place, it seems like that would be fairly readable? However, one way to make it more readable would be to create a builder for the ReportMetaData class. Here's an example for Java (though should apply equally well to C#): http://www.informit.com/articles/article.aspx?p=...


4

A simple format for storing tabular data is CSV. Attach it as a resource, just like you planned to do with the excel document. In theory you can even edit it using standard spreadsheed software, though there will problems with that: CSV does not encode types, so Excel will use heuristics to detect e.g. dates, which may corrupt data that looks like a ...


1

Starting in C# 6.0, getter-only auto properties have been added into the language. See here: https://github.com/dotnet/roslyn/wiki/New-Language-Features-in-C%23-6#getter-only-auto-properties. Here's an example: public class SomeClass { public int GetOnlyInt { get; } public int GetOnlyIntWithInitializer { get; } = 25; public SomeClass(int ...


1

On the one hand we expect convenience, on the other strict OOP principles being applied. If you implement too many convenient overloads, you will soon be implementing a universal type converter in a string class. And then something else. I guess keeping things mean and lean and sticking to the single responsibility principle outweighed the need for more ...


1

This constructor takes an array of chars as its input. For your use case, you can simply: var bar = new string(foo.Select(x => x).ToArray()); If you wanted a rationale, you could say that the lazy-loading behavior of the IEnumerable does not give you any added benefit here since you need to read the whole thing anyway to create the string. Whether ...


4

Since there is a constructor overload that takes an array of characters, this should work: var bar = new string(foo.Select(x => x).ToArray()); Which pretty much eliminates the need for another constructor overload, as the proposed overload would essentially have to do the same thing. Eric Lippert often discusses why certain features don't make it ...


2

What you need is a Unit of Work for your Repositories. The Unit of Work would have an interface similar to public interface IUnitOfWork { ITransaction Start(); void Commit(); void RollBack(); } then your save method on IOrderDataService and IOrderLineDataService would take an ITransaction, becoming: public interface IOrderDataService { ...


1

If you want to avoid SqlTransaction you may use TransactionScope from System.Transactions. This will have the added benifit that any systems that use MSDTC may use the same transaction. It also decouples your database from your business layer allowing the business layer to logically group your transactional data.


1

Persisting data to a date store (DB or other) isn't truly business logic, so I would push the SqlTransactionScope as close to the data layer as possible as it is controlling how the data is persisted/transacted. Your last method of: void Save(Order order, List<OrderLine> orderlines) This makes the most sense as the SqlTransactionScope would be ...


3

If you truly want to keep all of it separate, you could create your own TransactionScope interface and use that in your Create Method. The implementation of said interface then uses the SqlTransactionScope to do the "real" work.


-1

There are a number of .NET license protection products that will help you protect against your application being used illegally. Most of these tools work with a License Server and use the concept of online activation. This means that the first time your end-user tries to use your app, they are required to connect to a License Server to activate their ...


0

Actually, the "right" way is to NOT use a factory at all unless there is absolutely no other choice (as in unit testing and certain mocks - for production code you do NOT use a factory)! Doing so is actually an anti-pattern and should be avoided at all costs. The whole point behind a DI container is to allow the gadget to do the work for you. As was stated ...


0

There is no "right way", but there are a few simple principles to follow: Create the composition root on application's startup After the composition root has been created, throw the reference to the DI container / kernel away (or at least encapsulate it so it is not directly accessible from your application) Do not create instances via "new" Pass all ...


1

First I want to mention that you are making this significantly harder on yourself by refactoring an existing project rather than starting a new project. You said it is a large application, so pick a small component to start with. Preferably a 'leaf-node' component that is not used by anything else. I don't know what the state of the automated testing is on ...


0

You say you want to use it but don't state why. DI is nothing more than providing a mechanism for generating concretions from interfaces. This in itself comes from the DIP. If your code is already written in this style and you have a single place where concretions are generated, DI brings nothing more to the party. Adding DI framework code here would ...


9

There are two parts to your question - how to implement DI properly, and how to refactor a large application to use DI. The first part is answered well by @Miyamoto Akira (especially the recommendation to read Mark Seemann's "dependency injection in .net" book. Marks blog is also a good free resource. The second part is a good deal more complicated. A ...


24

Don't think yet about the tool that you are going to use. You can do DI without an IoC Container. First point: Mark Seemann has a very good book about DI in .Net Second: composition root. Make sure that the whole set up is done on the entry point of the project. Rest of your code should know about injections, not about any tool that is being used. Third:...


0

Correct approach is to use constructor injection, if you use What I'm thinking about is that I can create a few specific factories which will contain logic of creating objects for a few specific class types. Basically a static class with a method invoking Ninject Get() method of a static kernel instance in this class. then you end up with ...



Top 50 recent answers are included