I have a view which has different sections displaying different type of orders from DB (SQL Server). Now I need to refresh view with updated information each time a new order is submitted through Android Application. Below are code snippets:
ViewModel:
public class KitchenViewModel
{
public List<Orders> DisplayOrders { get; set; }
public List<Orders> PreparedOrders { get; set; }
public List<OrderItem> ProgressItems { get; set; }
public List<OrderItem> QueuedItems { get; set; }
public int DisplayOrdCount { get; set; }
public int PreparedOrdCount { get; set; }
public int QueuedOrdCount { get; set; }
}
Controller:
public ActionResult KitchenOrder()
{
KitchenModel kitchenInstance = new KitchenModel();
List<Orders> orders = kitchenInstance.GetProgOrdersList();
List<OrderItem> progressItems = kitchenInstance.GetItemProgress();
List<OrderItem> queuedItems = kitchenInstance.GetItemQueued();
List<Orders> prepOrders = kitchenInstance.GetPrepOrdersList();
List<Orders> queuedOrders = kitchenInstance.GetQueuedOrdersList();
KitchenViewModel viewModel = new KitchenViewModel();
viewModel.PreparedOrders = prepOrders;
viewModel.ProgressItems = progressItems;
viewModel.DisplayOrders = orders;
viewModel.QueuedItems = queuedItems;
viewModel.DisplayOrdCount = orders.Count;
viewModel.PreparedOrdCount = prepOrders.Count;
viewModel.QueuedOrdCount = queuedOrders.Count;
return View(viewModel);
}
As of now I am auto refreshing view after every 15 seconds which is working perfectly.
But I need to refresh view only when a new order is submitted through Android application and order is inserted in DB. Once a new order is submitted the values for PreparedOrders, Progressitems, DisplayOrders gets changed and need to be fetched again. I have read many posts/tutorials relating to Observer pattern and publisher/subscriber method but unable to get crisp solution which would fit best. Could someone please provide relevant pointer/tutorial to use in such a scenario that could help. Being this my very first project and a total beginner, I m quite confused as in how to proceed.
So if you have to update site on event that fires when something changes in base, as other clients have changed it, you need PUSH based architecture, and not PULL based like you do it now (requests on timer elapsed).
For this purpose you can use SignalR, that implements various modern communication mechanisms. The basic idea is: one time client accessed your site, there is a persistent
connection created pointing to it's browser, and in the moment of notification you just roll over all available clients and notify them. On client side, naturally, event is handled in your case with javascript.
Worth mentioning that this technology has limitations across browser versioning, so refer to documentation to see if supported browser versions set satisfies your requirements.
Here is the link to supported platforms list for SignalR2: Supported platforms
Related
I'm having hard time wrapping my head around on how to properly design my models in a console application while still trying to take advantage of EF core. For a bit more context, in a ASP.NET project you mostly only have to deal with a single request and is more "isolated" while the console application can grow infinitely more complex by having to maintain state and keep track of data.
For example, lets have a GameInstance which represents the current state of a game with active players connected to it. When the game starts, its state is loaded from a database using GameEntity model. While the game progresses, we need to save its state.
The first thing that comes to mind is to structure the following as:
public class GameInstance
{
private int Id { get; }
public string Name { get; private set; }
public string Description { get; private set; }
public int Score { get; private set; }
private List<NetworkConnection> connectedClients;
public GameInstance(GameModel model)
{
this.Id = model.Id;
this.Name = model.Name;
this.Description = model.Description;
this.Score = model.Score;
}
public void SetDescription(string description)
{
using (DbContext db = new DbContext())
{
GameModel model = new GameModel()
{
Id = this.Id,
Description = this.Description
};
db.Attach(model);
model.Description = description;
db.SaveChanges();
}
this.Description = description;
}
}
public class GameModel
{
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public int Score { get; set; }
}
But the drawback is pretty clear. All changes made require the database model to be reconstructed constantly which looks clumsy. Its also not great for allocations.
The second option is to store the GameModel inside the GameInstance and redirect the properties directory to the model itself. All changes can now be done directly to the model itself. Keeping the model around sounds more appealing but feels wrong.
The third option is to just have one class, the GameInstace and then configure EF core using the fluent API to do the right thing. This simplifies this scenario a lot and all changes can be done directly to the used instance. However, now you might need to introduce some database specific fields to the instance itself and the mix of properties required to keep track of the state. It feels like the single responsibility principle starts get cracks here. Also it makes it more difficult to use domain based architecture.
When dealing with REST requests in ASP.NET the user input comes in its own model like RequestModel. Then that is used to query the database to retrieve DatabaseModel and the required changes are done with the data from the request. Then the response is send with ResponseModel and all the objects can now be discarded and the single responsibility holds. It feels like EF core fits here perfectly. I don't feel the same with my console application.
How could I apply EF core to the console application cleanly? Am I missing something obvious? Am I overthinking this?
I am trying to understand and implement different UI patterns in .NET to see the pros and cons and where they suite best.
I understand the main concept but I was creating an app and a question appeared.
Say we have a class Customer, which represents the core Information of a customer.
public class Customer
{
public int Id { get; set; }
public string Name { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string Country { get; set; }
public string PostalCode { get; set; }
public string PhoneNumber { get; set; }
}
Now, if I create a WebView or WebForm to show all customers I can use this class to set as source f.e. to a DGV, being able to show all properties above.
But then I want to show for example a View/Form with the Revenue history of each customer.
So there is a class CustomerRevenue like
public class CustomerRevenue
{
public Revenue ActualYearExpectedRevenue { get; set; }
public IList<Revenue> RevenuePerYearList { get; set; }
public decimal ActualYearProjectedRevenue => CalculateYearProyection();
public decimal CalculateYearProyection(int year)
{
var daysInYear = DateTime.IsLeapYear(year) ? 365 : 366;
var actualYearRevenue = RevenuePerYearList.SingleOrDefault(x => x.Year == year);
var dayNumber = DateTime.Now.DayOfYear;
var projection = ((actualYearRevenue.Amount * daysInYear) / dayNumber);
return projection;
}
}
Here, to set RevenuePerYearList we need some time, since let's say we sell a lot and have a huge list of sells with huge lists of articles, so the calculation needs some time.
So now my question:
Should I then have "concrete" classes for each view/model with the data I want to show, i.e. here I would have apart of Customer class, say a CustomerRevenueModel
public class CustomerRevenueModel
{
private readonly CustomerRevenue _customerRevenue = new CustomerRevenue();
public int Id { get; set; }
public string Name { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string Country { get; set; }
public string PostalCode { get; set; }
public CustomerRevenue CustomerRevenue
{
get { return _customerRevenue; }
}
}
}
which has (maybe) different properties, so I need to load this "heavy" properties when needed
or
should I stay with only one class (I mean, a customer always has a revenue) and leave the properties "empty"?
The first option makes me have a lot of classes, one for each view/form I want to show data for (maybe being able to reuse some models in various views/forms) but keeps all clean and in a valid state. And also each class can have it's own logic (domain logic - DDD)
The second option is less classes, less code, but some way I end having a huge (God) class, with all the properties a Customer has and all it's logic (methods). I load only the ones I need, but this appears really bad to me.
The third option is to have the big class with all properties and methods as my (domain)model, and create a "ViewModel" (which contains no methods, only props) each time I need to show sth. like above , using it as source for my GridView. This is the solution with more classes and code (big class + ViewModels + (maybe) DTOs), but also the more organized and SOLID design to my eyes... Here the use of a Mapper like AutoMapper would really help, mapping between objects
But this is the part I'm confused about...
Are these "ViewModels" a bad pattern using MVC or MVP?
Are this the same as the VM in MVVM? Which I Think not, since I've understood VM in MVVM like a "template", but what I talk about appears to me more like DAOs??
Or they don't have nothing to do, are just DAOs
I think I am a bit confused about all the different meanings of Model, ViewModel etc, in the different design patterns.
I am hardly trying to understand right MVC,MVP,MVVM and DDD and I think sometimes I am mixing terms...?
First, try to not "mix" things from different patterns, ViewModels are for MVVM, and you NEED ViewModels if you want to implement MVVM (ASP.Net MVC uses something called ViewModels, but it is not the same than the ViewModels in MVVM design pattern)
The ViewModel is like a model for the View. The ViewModel work is to "convert" the Model(s) to something the View can understand.
You can have one o more models (or none) and use it in the ViewModel, you have a ViewModel for each View.
In your example (a datagridview) you can have a model that will represent the data in a datagridview, a DTO if you want, and you can have a property in the ViewModel, a List and you will fill with data loaded from the database. In the View, you will bind that property (the list) to the dgv datasource.
Think that the ViewModel is something like the code behind of the view, but you are working with properties and commands that will be binded to controla in the view.
At work I've got thrown into developing a legacy enterprice application, that still is under production and stalled for the last few months because of bad design and instability.
So we've started using EF5 and applying some design patterns / layers to our application.
What I'm struggling to understand is: what exactly should the Service Layer do in our case? Would it be over-architecturing or would it provide some benefits without adding unneccesary comlexity?
Let's show you what we've got so far:
we've introduced EF (Code First with POCOs) to map our legacy database (works reasonably well)
we've created repositories for the most stuff we need in our new Data Layer (specific implementations, I don't see any kind of benefit regarding seperation of concern using generic repos..)
Now in the specific case it is about calculating prices for an article - either by getting a price from an arcile directly or from the group the article is in (if there is no price specified). It's getting a lot more complex, because there also are different pricelists involved (depending on the complete value of the order) and depending on the customer who also can have special prices etc.
So my main question is: who is responsible for getting the correct price?
My thoughts are:
The order has to know of the items it consists of. Those items on the other hand have to know what their price is, but the order must not know of how to calculate the item's price, just that it has to summarize their costs.
Excert of my code at the moment:
ArticlePrice (POCO, Mappings soon to be swapped by Fluid API)
[Table("artikeldaten_preise")]
public class ArticlePrice : BaseEntity
{
[Key]
[Column("id")]
public int Id { get; set; }
[Column("einheit")]
public int UnitId { get; set; }
[ForeignKey("UnitId")]
public virtual Unit Unit { get; set; }
[Column("preisliste")]
public int PricelistId { get; set; }
[ForeignKey("PricelistId")]
public virtual Pricelist Pricelist { get; set; }
[Column("artikel")]
public int ArticleId { get; set; }
[ForeignKey("ArticleId")]
public virtual Article Article { get; set; }
public PriceInfo PriceInfo { get; set; }
}
Article Price Repository:
public class ArticlePriceRepository : CarpetFiveRepository
{
public ArticlePriceRepository(CarpetFiveContext context) : base(context) {}
public IEnumerable<ArticlePrice> FindByCriteria(ArticlePriceCriteria criteria)
{
var prices = from price in DbContext.ArticlePrices
where
price.PricelistId == criteria.Pricelist.Id
&& price.ArticleId == criteria.Article.Id
&& price.UnitId == criteria.Unit.Id
&& price.Deleted == false
select price;
return prices.ToList();
}
}
public class ArticlePriceCriteria
{
public Pricelist Pricelist { get; set; }
public Article Article { get; set; }
public Unit Unit { get; set; }
public ArticlePriceCriteria(Pricelist pricelist, Article article, Unit unit)
{
Pricelist = pricelist;
Article = article;
Unit = unit;
}
}
PriceService (does have a horriffic code smell...)
public class PriceService
{
private PricelistRepository _pricelistRepository;
private ArticlePriceRepository _articlePriceRepository;
private PriceGroupRepository _priceGroupRepository;
public PriceService(PricelistRepository pricelistRepository, ArticlePriceRepository articlePriceRepository, PriceGroupRepository priceGroupRepository)
{
_pricelistRepository = pricelistRepository;
_articlePriceRepository = articlePriceRepository;
_priceGroupRepository = priceGroupRepository;
}
public double GetByArticle(Article article, Unit unit, double amount = 1, double orderValue = 0, DateTime dateTime = new DateTime())
{
var pricelists = _pricelistRepository.FindByDate(dateTime, orderValue);
var articlePrices = new List<ArticlePrice>();
foreach (var list in pricelists)
articlePrices.AddRange(_articlePriceRepository.FindByCriteria(new ArticlePriceCriteria(list, article, unit)));
double price = 0;
double priceDiff = 0;
foreach (var articlePrice in articlePrices)
{
switch (articlePrice.PriceInfo.Type)
{
case PriceTypes.Absolute:
price = articlePrice.PriceInfo.Price;
break;
case PriceTypes.Difference:
priceDiff = priceDiff + articlePrice.PriceInfo.Price;
break;
}
}
return (price + priceDiff) * amount;
}
public double GetByPriceGroup(PriceGroup priceGroup, Unit unit)
{
throw new NotImplementedException("not implemented yet");
}
//etc. you'll get the point that this approach might be completely WRONG
}
My final questions are:
How do I correctly model my problem? Is it correct, that I am on my way of overarchitecturing my code?
How would my Service Layer correctly look like? Would I rather have a ArticlePriceService, an ArticleGroupPriceService, etc.? But who would connect that pieces and calculate the correct price? Would that e.g. be the responsibility of an OrderItemService that has a method "GetPrice"? But then again the orderItemService would have to know about the other services..
Please try to provide me with possible solutions regarding architecture, and which object/layer does what.
Feel free to ask me additional questions if you need more info!
You did present a simple scenario which the Repository itself might be sufficient.
Do you have more repositories?
Do you expect you application to grow, and have more repositories in use?
Having a service layer that abstract the data layer is recommended and in use by most of the applications/examples that I have seen, and the overhead is not that significant.
One reason for using services might pop-up when you would like to fetch data from several different repositories, and then perform some kind of aggregation / manipulations on the data.
A Service layer would then provide the manipulation logic, while the service consumer would not have to deal with several different repositories.
You should also think of situations where you might want to have more then one entity changed in one transaction (Meaning - more than one repository), and saving the changes to the DB only when all update actions where successful.
That situation should imply using the Unit Of Work Pattern, and probably will conclude the use of a Service Layer, to enable proper unit-testing.
When i started with objects and architecture, my main problem was to give a good name to classes.
To me, it seems your service should be called "ShopService" (or something equivalent). Then your method GetByArticle, should be nammed GetPriceByArticle.
The idea of changing the name of the service for something bigger than just the price would be more meaningfull and would also address other issues (like your OrderPriceService you wonder about).
Maybe you can ask yourself "What is the name of my page or window that interracts with this service ?" Is there only one or more ? If more, what do they have in common ?
This could help you figure out a good name for your service, and consequently different methods to acquire what each needs.
Tell me more. I will be please to help.
I'm struggling with the design aspect of building this web site, its my first website and I'm not sure of the correct direction i need to take this project in. I've posted on this previously but not done a good job of explaining it. So I'll attempt to do so now.
The Site will be used for submitting "Innovation Ideas" from employees. It will have to connect up to an already existing MS Access Database. There will be two tables in this database that it has to communicate with.
The first one Is the InnovationSubmission Table which which looks similar to this :-
ID(Auto Generated),
Short Description,
Long Description,
Name,
Email Address,
Date(From Date.Time.Now()) - on Submission.
Team Name
Area (Area of Business)
The User will use a Web Form(View) to enter the details above, it will be validated, then saved to the back end database. I have this working in a fashion. The issue has started when I have tried to introduce two DropDownlistsFor contorls based on another table which is below :-
AREA A - Team1, Team3, Team5, Team7
AREA B - Team2, Team4, Team6, Team8
This is just sample Data, there are only two different areas in the table, but there will be over 50 teams split across them. I will be looking to have the Teams dropdownList filter on the value in the Area DropDownlist.
In my Models folder I have created a InnovationSubmission Class, that replicates the table in the database, this class is used as a strongly typed data type in the View representing the Submission Form. Its how i Validate the User input and I pass this class to a c# method that sends the data back using ADO.NET.
I'm struggling with how I should be trying to implement the dropdownlists.
Will I need to create a class similar to the InnovationSubmission Class, to represent the Teams/ Area Table?
Is the table at present structured in the best way for this project?
Can I populate both dropdownlists from the 1 table?
How do I relate the Teams & Area Columns?
Any Help would be greatly appreciated!?!
Would this be the correct way to design my View Model :-
public class MyViewModel
{
public int ID { get; set; }
public string shortDesc { get; set; }
public string longDesc { get; set; }
public string Status { get; set; }
public string originator { get; set; }
public string originatorEmail { get; set; }
public IEnumerable<Area> area { get; set; }
public IEnumerable<Team> team { get; set; }
}
public class Team
{
public string teamName { get; set; }
}
public class Area
{
public string area { get; set; }
}
You seem to be talking about cascading dropdown lists where the values of the second one update based on the selection made in the first one. I have illustrated an example of how this could be achieved in this post. The idea is that you subscribe to the .change event of the first dropdownlist and then trigger an AJAX request to a controller action passing the selected value in which you wold query the database and return a list of possible options.
Ok I've been trying to figure out the best way to do this for a few days, but still haven't come up with a very elegant answer so am hoping I someone can point me in the right direction or give some peer review :)
Basically I have 3 classes (they are different and much more complex than these):
public class Person
{
int ID { get; set;}
string Name { get; set; }
virtual IEnumerable<Place> { get; set; }
}
public class Place
{
int ID { get; set;}
string Name { get; set; }
virtual IEnumerable<Thing> { get; set; }
}
public class Thing
{
int ID { get; set;}
string Name { get; set; }
virtual IEnumerable<Place> { get; set; }
virtual int PersonID { get; set; }
}
So basically you have Persons, who have many Places, which can have many Things which can also appear in multiple Places (trying to reduce having to store duplicates of Things) but only for that Person
What is the best way to setup my ViewModel to handle this? Should I just create everything by itself using Ajax and Json (what I've been doing) or is there a way to handle this type of relationship in a ViewModel and single post back to the server?
Currently I'm doing the following:
Fill out Person form -> ajax save to server, get Person ID
Fill out Place form (including Person's ID) -> ajax save to server, get Place ID
Fill out Thing form (including Person ID and Place IDs in a delimited string
I know there should be an easier way to do this as its kinda bulky, but since its all query string I can't figure it out
You say "kinda bulky," but I think it tends to be more lightweight if you can build an object graph on a form in real time by using AJAX/JSON, probably against a RESTful API, somewhat as you describe.
The alternative is using script (jQuery, JSMVC, Knockout) to build a form and POST the whole sucker at once. I've had to do this in some situations where none of the data should be persisted until the whole graph is committed. The trick here is understanding ModelBinder and how it builds/updates that graph for you.
If this is what you were asking, I can expand on the key points of how ModelBinder deals with complex object graphs and collections.
I answered a similar question about how to handle this using interfaces and partial views.
How to create Asp.Net MVC 3 view model