|
Our company is currently running .NET version 4.5 and using VB as the back-sript language. All of our forms are basically using the general ASP.NET forms methods. In other words we are not taking advantage of the any of the MVC core methods.
We are getting ready to start our new design process and wanted to get some recommendations on what framework and mythologies/C# version/database methods/Web UI methods, to use in our new design.
Any advice would be grateful,
Thanks,
Steven
|
|
|
|
|
The answer is: It Depends!
What skills does your team have / how much new learning are they able to do?
Are you intending to run the old stuff concurrently with the new stuff or is it a big bang approach?
What is the problem domain? That will dictate what are the best tools for the job
Are you willing to risk leading edge (which may be buggy) or do you want trailing edge (which may cause upgrade issues in the future) or do you want to play it safe (e.g. go with the next-to-latest version)?
Who are your clients / customers? What will they be most comfortable using?
Are there off-the-shelf packages that can do what you want which could save you a lot of development time?
Stevey T wrote: recommendations on what framework and mythologies/C# version/database methods/Web UI methods, to use
Do not use mythologies: they are not real!
|
|
|
|
|
Hello,
In my company we had a system on .net framework platform. That was made from an orchestator, different rest API services on top of a monolithic oracle DB. With a huge plsql library.
We used distributed transaction for the operation (import of data). Because of the rollback possibilities if one request did fail e.t.c. And used a orchestrator in front of the rest API services (micro services) that organized the different requests all in one transaction.
We had to upgrade the system to .net core.
But .net core don't support DTC anymore !
Have anyone had a similar situation, and what what did you do about it?
Or do anyone have any comments to this issue/problem.? That if one request fails in a
big operation of many requests the database data will not be consistent, if no rollback is done.
When we use many "micro"services on top of one monolithic database.
BR
|
|
|
|
|
I think a DTC implies "multiple" "micro services".
A transaction that spans multiple databases is not what I would can micro.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
We are thinking of building an internal Kaggle like platform to run Hackathons in our company. I am wondering what would be the best technologies to use for this and how to go about building such a site. Any help appreciated. Thanks.
|
|
|
|
|
So we need to first visit Kaggle to know what you're talking about? And then we come back here to ask you questions about Kaggle?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
|
I have always had the view that duplication is bad. There are always exceptions, but most of the time I it seems bad to me. Unit tests are one are where I tolerate it more but in production code it's something that I rarely find desirable.
Some people duplicate things two or three times and only eliminate the duplication on the third or fourth time. I really can't understand why somebody would blindly follow this rule. I understand the argument that we may not know how to refactor something if there are aren't enough instances of the duplication but I find that it is rarely the case. At least if you don't know how best to refactor something then keep it simple. The rule seems crazy as why would you do something if you know it's bad? Eliminating duplication is usually quick and, in my opinion, usually makes things much easier to read, particularly when you have half as much code to read/understand.
As an example, imagine we want to format a number as a currency. We could have the following
x.ToString ("£0.##")
Having it once seems fine, but not really more than once. Surely, as a very simple refactor, something like the following would be better?
Format.AsCurrency(x)
Surely the time saved by the readability would outweigh the code of writing it and it solves the problems of duplication.
Deliberately duplicating code doesn't make much sense to me, but maybe I've been working with people who have taken things a bit too far?
|
|
|
|
|
The principle of Do not Repeat Yourself (DRY) is one of those areas that is taken too far by some code zealots. Let's take your ToString example here, you notice after a couple of times that you have the same ToString code so you decide to introduce an AsCurrency method. That seems straightforward enough, but you're working in a large codebase so you don't notice that the same logic has been added in pieces of the code that you don't visit. Worse still, somebody has done this elsewhere:
Then there was that piece of code which looks like this.<pre>public class FormatConstants
{
public const string GBP = "£0.##"l
}
...
return myItem.ToString(FormatConstants.GBP);
...What we're seeing here is that others have attempted to avoid repeating code with varying degrees of success. In all of these cases, there is an element of repeated code because differnt people have taken different approaches to to avoid repeating code. Even if the code doesn't look exactly the same, you are repeating the intent of the code. Now you have introduced yet another way to represent this same conversion. In six months time, someone else comes along and has to add a currency ToString in a few places so they refactor their code to avoid adding repeated code. If you're lucky, they have looked through the codebase looking for other places that does the conversion and picks an already written one; if they've searched using ToString("£0.##") then they might not have found the match so they end up adding yet another new way of formatting this one item. What has happened here is that the search to remove duplication has ended up creating a mess - and this is just with a simple example.
The bottom line is, DRY is a great principle and one that you should try to stick to if it makes sense but you have to accept that, in some cases, you aren't going to achieve it and you shouldn't beat yourself up over it.
|
|
|
|
|
Contrast duplicating, inlining and premature optimizing.
Or the fact the "pattern" may not yet have fully materialized in the mind.
It's not the first time one has pulled together "similar" code only to realize you just dug a deep pit because you didn't consider the full impact.
Which is very easy in the "agile" environment where they pump out bits of code in ignorance of the big picture.
As for the ToSTring() example, I use xxxAsSomething() ... which inevitably winds up including xxxAsSomethingDifferent(), etc.
I've now established a pattern that creates functions out of everything ... even "one-timers". And then programming becomes a real drag.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I decided to start to learn web programming and as a first serious project I want to build a stocks/cryptography portfolio, where user sign in and add their holdings of specific stocks/coins. Users can see the current evaluation of their portfolio, or inspect various types of charts. I would like to host my app in the cloud, so that everyone on the internet can access it. Such sites(with lots of other features) are coinmarketcap.com or coingecko.com .
I have no idea what technologies to use, I know there are plenty of options, so that makes it very difficult for me to make a choice. I would like to use modern but popular technologies, which ideally are relatively easy to learn. I googled for an hour or so, and these technologies were mentioned:
- Google Cloud Platform: Google Cloud Run, Firebase (+ Firebase Realtime Database, Firebase Realtime
Database, Firebase authentication)
- All kind of products from AWS
- Docker, Kubernetes
- Angular, React
- NodeJS, Express
- Python(for backend)
I'd prefer Google Cloud products over their AWS alternatives. I have some experience with Angular, Docker, Kubernetes, NodeJS + Express, and Python. I have no experience with GCP or AWS, but I think I'd enjoy learning them.
So, what technologies (from the ones above, or others), would you recommend for my basic project ? The project basically needs cloud hosting, user authentication and database storage.
Thanks for your time 
|
|
|
|
|
Without getting into architectures, you do know you don't need "cloud hosting" in order for people to visit your site? "I would like to host my app in the cloud, so that everyone on the internet can access it."
Cloud hosting of course has advantages (scalability, resilience, potentially performance etc) BUT if you're new to web development, is a large learning curve in its own right. I've been doing web development for 20+ years but both Azure and AWS are so complex to configure, and so unpredictable in terms of pricing (and potentially very very expensive) that to date I've steered clear.
Unless you expect mega take-up of your app, all you need is a basic shared hosting plan with a MySql or SqlServer database, at a cost of under $5 / month in total. It will be much easier to configure and manage, and allow you to concentrate on your application.
Your tech lists above are comparing apples and televisions (not even apples and oranges). Generally, the languages you build your app in are unrelated to the platforms you host on (with some limitations).
|
|
|
|
|
First time poster, long time visitor.
TL/DR: What kind of design patterns are useful for the following project:
Frontend: Web/Mobile, simple Word finding game (4x4 board with 16 letters, connect letters to make words)
Backend + database: Check if word exist/ Save scores for highscore/ Save generated boards/ Users/ etc. (I'm planning to use Repository and Unit of Work for Database, and Singleton for settings, userId, etc.)
Long story:
I'm currently working on the last assignments of my study, and have hit a mental wall for quite some time
One of the assignments is for a class called Design Patterns, where we have to make a drawing program with specific design patterns or use design patterns in a project of our own.
After failing multiple times trying to build the standard assignment, I'm thinking of combining my last two assignments into one, and creating a web-app/mobile-app with backend and database.
Frontend would have a 4x4 board of buttons, with letters on it. The buttons can be tapped and a word can be added.
The backend would check if the word exists, if the word is playable on the
Database will keep highscores, userinfo, earlier generated boards, etc.
I don't know a lot about design patterns, so I was hoping some people with experience could help me with some useful design patterns that I could use. The ones I do know I could use are Repository and Unit of Work for the Database, and Singleton for saving settings and UserId on the mobile app.
|
|
|
|
|
When it comes to web applications, the common UI patterns to apply are some combination of Model View Controller, Model View, ViewModel or Model View Presenter. If I were you, I'd look at what you can do with those. If you have experience with more complicated applications then another common pattern to apply is the use of Observables.
Normally I would advise against designing a system just to use patterns but if your assignment is to use patterns then that's what you are going to have to do.
|
|
|
|
|
Thanks for the reply.
I agree that designing a system just to use patterns isn't a great idea, this is why I had trouble working on the original assignment.
I have worked with MVVM, and use it in every mobile app I have made so I'll use it for this one as well.
Thanks for the advice
|
|
|
|
|
I Agree. I always think of Patterns as being mostly useful as you're writing, as you spot situations that match the pattern, rather than being the goal itself.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
|
I'd like a bit of help with terminology/practices around models and DTO's.
If it makes any difference to the answer, this is a blazor client/webapi server in C#, and there will be a database ORM (likely EF) at some point.
I've got some simple plain object classes that I've been calling Models, and each of these contain the properties for one 'thing' in my application.
Now one part of my UI wants to display data from multiple of these model classes. Now I'm pretty sure you don't want to get all of data from each model and combine on the UI. I'm also pretty sure I can't transfer an anonymous type over a webapi call? Or at least I couldn't easily work with it if I did.
So I think I want to create a second class that has the properties from both the parent classes I want to use, the server part does the combining and transfers that class.
So is this combined class more commonly referred to as a DTO? and that for ease of understanding I should separate that from my main model classes?
Also if I do just want all the data from a model class, I dont need to create a seperate DTO just for that, and its ok to just reuse the model class?
thanks
|
|
|
|
|
DTO stands for "data transfer object", so technically anything you return from your API will be a DTO.
The problem with reusing model classes, particularly if you're using an ORM like Entity Framework, is the navigation properties. For example:
public class Customer
{
public List<Order> Orders { get; set; }
}
public class Order
{
public Customer Customer { get; set; }
public List<OrderLine> Lines { get; set; }
}
public class Product
{
public List<OrderLines> OrderLines { get; set; }
}
public class OrderLine
{
public Order Order { get; set; }
public Product Product { get; set; }
} If you now want to return the details of a single order, that will include the customer, which will include all of the customer's orders. Unless your serializer can handle it, you already have a circular reference.
But it gets worse: each order line will return the product. And each product will return all of the order lines which use it. And those will include the details of the order they're associated with, which will include all of the lines for that order. And each order will return the details of the customer, which will return all of the orders and order lines for that customer.
Pretty soon, you're returning almost everything from your database just to display the details of a single order!
It's usually better to create specific DTOs to represent just the data you want to return, with no circular dependencies. You can use a tool like AutoMapper[^] to simplify mapping between your model classes and your DTOs.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
A DTO (data transfer object) is like a pack animal; it's used to move data around as a convenience; they're not part of the "official" model. A DTO comes to mind (for example) when you have to pass "a lot of parameters"; a DTO class is tidier. It's said they shouldn't have methods, only data; but I see no reason not to have special getters, setters and the like if its convenient
Your EF classes would be considered part of your official model; but a single class is not typically referred to as a model; "entity" maybe. Model data (entities) are typically stored (eg. in a db); DTO's aren't.
And, yes, when you retrieve an entity from EF, you can use it "as is"; bearing in mind that these entities can be in different "states" (attached, detached, modified), depending on you requirements at the time.
And your UI can have multiple / different entities (from different tables); eg. the classic "sales invoice" with header (entity1) and details (entity2); the parent-child relationship.
And data typically gets passed in a web service as XML which you put together as you please (according to spec). see: Data Contracts.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
modified 11-Nov-20 4:05am.
|
|
|
|
|
And here is why some of us never use EF!
I would normally create a model that reflects the data required by the view (sorry I'm WPF oriented), so a request for order details would populate only the order, item lines and customer details for the order requested and pass the single object to the client.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I think the WPF model concept is where I was initially coming from, as that still seems a good idea for a Blazor wasm app. Even if the V/VM part is a little different.
The webapi (or a service behind that) can do the translation between what I want to show and EF or any other database interaction.
|
|
|
|
|
I'm working on a busisness app for a client. Right now it's a WPF app. I have the UI layer, the BL, and the DAL. 99% of the BL just passes the call to & from the UI/DAL.
Now, I'm going to be introducing a Tablet piece. In the WPF app's ViewModels I have a Validate method which checks to see if the required fields are filled in, and also some business logic. One example is "You cannnot save a Job if the Approiver has not been set"
So, in the tablet app, I'm going to want to do the same logic.... when the user clicks Save, validate required fields and apply business rules. So It seems to me that the BL is a good place for this.
However, its also seems that passing all the data across the web to a Web API, only to have it rejected in the BL, isn't right.
Is this the right approach?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
modified 2-Nov-20 15:34pm.
|
|
|
|
|
I'd be inclined to have a shared class library of DTOs used to communicate with the API, and put the validation in there. Then have the UI view-models delegate as much of the validation to the DTO as possible.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: I'd be inclined to have a shared class library of DTOs used to communicate with the API, and put the validation in there.
That would be fine if the only issue were missing property data. The DTO'scould validate themselves. But in the case of business logic, there are times when you would need to go to the data.
Plus, putting the validation in the logic means that the DTO's can only be used in that app. If you then created another app that uses the same data, then the DTO's are now housing logic specific to the first app. The second app may not require the same validation.
IMHO, DTO's should be dumb objects that do nothing but carry data.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
