Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Recently I'm reading an article about http://ardalis.com/n-tier-design-lessons-learned-part-1 which introduce the evolution of n-tier application but one thing was not explained is the WorkFlow layer can anyone one explain what's the workflow layer and give us a real world application example with c#.
From here:
By creating a workflow tier a company has essentially avoided
hardcoding workflows into one of the other tiers. By creating a
workflow layer, we will gain the added flexibility easily
customizability that a tier provides. We will gain improve
manageability of the workflow tier by extracting the layer. For
example, when the end user requests changes to the workflow, by
creating a specific workflow tier and thus isolating the
responsibility of workflow the resulting code changes will be
minimized to just the workflow tier. The impact on other tiers will be
minimized.
Also check To Workflow or Not to Workflow?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I can't wrap my head around what to choose between these 2 flows, in these diagrams I'm using mediator pattern but it does apply to any use-case that has a layer for an interface ( API ) and the application itself ( Domain ).
Should I enforce DRY and return the response from the domain directly to the client. But add a separate DTO for incoming requests that is processed by the interface and map it as a domain model.
Should I enforce SOC and map all objects coming in and coming out of the domain. One of my major pain points is that adding a new property would require me to update all my objects both on webapi and domain.
I'm curious around what the community currently practices around DTOs on a layered architecture, I've been searching both here and in github repos and most implementations follow the first one ( albeit those were only "sample" projects )
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I want to send Email and SMS in bulk in c# MVC. So, method would be better, cron in a web application or separate scheduler service for it?
I have a web application running already. So, should I integrate the cron in the web app itself or create a new scheduler service for it.
I want to use the best method in terms of reliability, speed and load of data.
its better to make separate service for that for the below reasons :
1- Maintainability : If there is a problem in sending mails or SMS you know where you need to check without going to your main solutions.
2- Availability & Scalability : You can scale this Module only or if any thing happens to your main app, your mailing and sms will still be working.
3- Separation of Concerns : SMS and Emailing is considered to be a cross cutting functionality that it will be used in alot of places in system, so it is better to have it in one separate place.
4- I/O latency : like this you will avoid any latency or any performance effects on your main business domain.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm writing an application in WPF and found myself loving whole MVVM paradigm. My only concern at the moment is that my ViewModels are becoming heavy. They contain Commands, logic to enable and disable buttons, instances of other ViewModels, async method with DispatchTimer timers etc. Is this something that is normal in this kind of development environment? Or is there some logical way of organizing ViewModels without becoming too "crowded"?
Keep in mind that the ViewModel is just an adapter between your model, where logic and data live, and the view which is shown to the user.
The idea is you can easily swap views or change them, without the logic suffering from that.
Having said that, depending on the complexity of your application, they might grow quite big, but if it's mainly stuff that ends up enabling/disabling stuff on your view, and isn't doing logic / processing stuff, I'd say this is where it's supposed to live.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
For my company, I have developed one winform application, that handles Unified COmmunication.
It's been 1 year in development. I Just write global functions in seperate classes, and write the code in either form or class. Now They wanted me to make three seperate copies(UI of each changed) of the same Software. I have changed all UI and everything needed, and made 3 copies. But now, I feel it very difficult to correct any issues, or add any features. I have to change it in my all three copies. How can I solve this. Thanks.
I'll assume the three versions are very similar. First off, it's of the utmost importance that you keep your project under source control.
Personally, I would have created a dev branch for the main version, and then create two other branches for the 2 other versions (e.g., dev-v1 and dev-v2), created off the main branch.
Then, whenever I had to apply a patch to all 3 versions, I'd do it on the dev branch, and then merge dev with dev-v1 and again with dev-v2.
So far I only addressed the source control issue, but as CSharpie pointed out in the comments, you should definitely separate the presentation layer (i.e., forms) from the business logic. Furthermore, these two should also be separated from the data layer.
Take a look at Multitier architecture.
Separation doesn't necessarily mean different projects or solutions. Having a logical separation (e.g., having sets of classes with very well defined purposes, following the SOLID principles etc.) is often enough. In your case, however, it seems that the presentation layer should be in a different project than the other two.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
As Big Data term used widely to manage huge data, I want to give a try to build a small application with Big Data to understand structure and how I can start with ASP.NET technology?
Is it possible?
"Big data" is a marketing term for "highly scalable large load computing". So can you use ASP.NET for highly scalable large load computing...
Yes, and here is how (Scaling Strategies for ASP.NET Applications).
Adding to Scott's answer, apart from ASP.NET being capable of scaling to high loads with effective strategies, .NET ecosystem also provides HDInsight in Azure, which implements MapReduce programming model to query over large clusters of Data.
Azure HDInsight could closely be related to the marketing buzzword of 'Hadoop','Big Data' etc.