In general, (far) shallower inheritance hierarchies. Instead of overriding all of these behaviors, consider injecting them. All of these variations can then be simple static functions (since they take arguments and contain per-instance state). It also makes the FromJson or FromCsv sort of factory methods more discoverable.
This sort of approach should ...
I feel that c# has become a very wordy language and I'm not happy to have to code in the async style like this.
Oh, but that is not wordy at all. You are not writting something like this:
response => response.Content.ReadAsStringAsync().Then
Telastyn's recommendation is a good one in general. However, I think what you have shown in your example can be still a reasonable inheritance hierarchy, and changing it may not be the right solution for this case.
But there are some well-known, simpler techniques to deal with the shown problem without a complete redesign of the class hierarchy, and often ...
Enums are intended for things that are unlikely to change.
For example, a traffic light has three colors: red, green and yellow. That would be a good candidate for an enum. Even if you included all of the possible shapes such as right-arrows and left-arrows, that would still be a good candidate for an enum.
To change the colors or shapes of a traffic ...
Flight pattern analysis seems to be a big thing in you business logic. It is so common that replacing it with Fpa won't hurt. The people in the company are probably using the abbreviation already anyway. The class documentation header can spell it out once.
If you must have "UsingSomeFileFormat" descendants (which I doubt, you should probably use separate ...
From OOP and C# perspective the example code doesn't violate SRP. Data and basic operations over it belong together, that's what classes are. The idea to separate data and logic should be applied on higher level in large applications, e.g. business logic should be separate from data persistence.
One can make other remarks on the code, not related to SRP. ...
The project I'm working on is web based price calculation
I'll only be here for 3 months and there are nobody in the office that can do any coding
Note that these two statements are already showing the main issue here: if the company for which you are working really wants to offer a web based price calculation in a permanent fashion - ...
With just the interface as information, it is impossible to say if a particular pattern is being followed. It does appear that an attempt is made to separate the user-interface from the business logic, which can indicate that the design is inspired by the MV* patterns.
As for where the timing should be handled for how long messages/dialogs are presented to ...
C# supports reflection, so you can write a solution to take advantage using introspection. You would use XmlClass.Convert to convert foo (or any class).
In more general terms (and not specific to C#), if you are using a language that does not support reflection you should have foo do the conversion. This is because foo knows the details of what a foo is; ...
As there is no standard way to get such a behaviour, and if you really need it, then by all means that is a valid approach.
It may even be desirable to implement your own helpers to facilitate easier/more explicit use of this pattern, either with standard Lazy or your own special-tailored LimitedConcurrencyNoErrorCachingLazy.
public class ...
You need metadata
In order for a user to be able to add custom card types that may or may not have specific business rules or behavior, the user must be able to specify whether the behavior applies, and you need to be able to store it.
So you will need a metadata table, sort of like this:
CREATE TABLE CardTypes
Another way to solve it using the Design Patterns Strategy and Factory Method:
An interface defines the strategy, in this case, it say that the strategy is write something, without details about what.
For each variation of the strategy you implement the IStrategy:
class StrategyA : IStrategy
DRY principle prescribes to avoid duplication of different pieces of knowledge, not just repeatable blocks of code. Two identical blocks of code can correspond to very different rules and that's totally fine to have such "duplication". In this specific case, data required by view and data required by persistence layer are two different pieces of knowledge ...
Think about the redundancy you are seeing in all of these names. "FlightPatternAnalysis" is repeated over and over and over. Due to the repetition, it does not provide any value, and actually makes the API harder to comprehend. I work on a project where the name of the project is used so often that you can't find where any code you need to change actually ...
Make a .net web service that receives the data submitted by the form.
Add that data to a database, using transactions to maintain consistency
After adding the data to the Database call a second FileExport
FileExport reads the database, generates the file and writes it to the s3 bucket.
FileExport also buckets incoming requests. So if you get 50 updates ...
I basically need a factory function inside my DomainModel that accepts a PersistanceModel and do not trigger any events, is this smelly good?
In practice, that's probably going to work out fine. Here's the key point
I know some of you will say that this model can be refactored etc, but since I'm writing software for my organization and we use old ...
If you only ever deal with webservers and other highly I/O bound applications, sure you'll see a lot of async stuff and not a lot without. However, there are still plenty of people writing software for desktops and mobile devices that aren't IO bound where async is not as beneficial, and not used as often.
In any case, many libraries use it because async/...
Data and logic do not need to be separated to satisfy SRP. In fact, I do not think you should be doing that, not even for functional programming. Yet, will get to that.
About your code, at method level you are not breaking SRP. However, at class level you are. Let us speak in reasons to change...
You could have to change your code if:
You decide to change ...
The fact that they've asked you to do this suggests that they're at least willing to look at other ways of doing this - perhaps as a proof of concept/trial balloon.
If you design it in a modular way, the fact that nobody codes isn't an absolute barrier in itself (although it is a substantial risk given the paucity of expertise). As long as they can edit the ...
If a node may have multiple parents, it is not a tree structure, it is a directed graph. By introducing the red arrows you now have cycles in the graph, which means you cant really talk of parent-child relationships or hierarchy levels anymore.
Cycles also means you can't just traverse the graph until you find the node matching a predicate, since you might ...
I will only comment on the design and the code from the perspective of DDD. Specifically, using the free DDD Reference by Eric Evans, pp. 9, 10 and 17 (layered architecture and repositories).
According to Domain-Driven Design, domain model layer should not depend on any layer, right?
I think you incorrectly interpreting a statement like this:
public void Deposit(int amount)
This is the part of your code that is a bit weird, in terms of Domain Driven Design.
The domain model is usually composed of pure in-memory representations of your domain; they own their own data structures. So you either send them information so that they may ...
It is a good practice to introduce an intermediate "Application Service" layer between your controller (here, your Console UI) and the Domain Layer.
The App Service will be responsible for invoking the (injected) infrastructure services, calling the domain layer and also persisting/loading necessary data. The Controller's responsibility is only to gather ...
Lets say you have 100 incoming calls to your webserver. All 100 starts to exeute a SQL query. 99% of the call is spent waiting for SQL to return a result.
Wouldnt it be better to return the thread to the pool and serve another request while SQL is working?
You can also benefit in UI code by using tasks. Prior to Tasks tools like Unity 3D and Caliburn Micro ...
The three examples you gave all have the same operational model: Request, Update, Respond.
Essentially they are CRUD operations and so we could answer your questions as:
It is doing one thing: the U in CRUD.
Why not? The purpose of this business logic is to perform a simple update of a single domain entity. There is no reason to distribute the logic on ...
This is just my opinion, but I feel like I disagree with Ewan in some ways.
I think it depends.
I think I definitely wouldn't be returning the EF objects to your client. I would use a package like AutoMapper or whatever to map them to DTO objects that is used only for transporting data to and from client.
However, I don't think it's necessarily bad ...
Best practice is to hide the EF stuff.
This allows you to share you models without forcing the EF dependency, maintain a separate data layer, run unit tests etc etc
You can do this by mapping the EF generated to your models, or by using code first models if you don't end up having to add attributes to them.
I would add an extra Project.Repository to ...
I'm going to start with detecting cyclical dependencies. This can be done by checking if a dependency is part of the chain leading to that dependency, i.e. something like this:
private static bool IsCyclic(IResource resource)
var stack = new Stack<IResource>();
Fire and forget is what we actually did. The less code you have in the application that is initiating the log message the less code that you have to debug there.
All you actually need to do is write your messages to a logfile(s), and spunk can be configured to process those log(s). You may want to have a process that queues the log messages and that ...
Start by creating a folder within the solution by separating projects by features or departments and one folder for cross-cutting or shared projects as you prefer.
After that, within each folder you created for each feature you can add other subfolders to Data Access, Domain Model, Application and UI.
This already will be a good start to application of DDD....