|
|
Thank you for the answer!
I will look into it 
modified 28-Oct-22 21:01pm.
|
|
|
|
|
we have a vending machine project and we need a help today
In this project, you will design a vending machine that will accept at least two different coins (5 kr, 10 kr, 25 kr, 50 kr, 1 tl) and will output at least 2 products. For example, one group can choose 5 kr and 10 kr, and dispense 2 different products while another group might decide to use all the coins, (5 kr, 10 kr, 25 kr, 50 kr, and 1 tl) and dispense 3 or 5 different products. Groups are free to determine the count, the name and price of each product in their projects. For example, you can choose gum (20 kr), soda (35 kr), and chocolate (65 kr).
|
|
|
|
|
As you were told when you posted this in QA[^], we are not here to do your homework for you.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Guys, I am looking for a Design & | Architectural suggestion for my Application which should work for different types of clients: (Thin Client(Browser), Thick Client(WPF), mobile application) and DataBase can extend to Cloud in future
Proposed:
MVC Pattern, Client-Server architecture
Presentation Layer: HTML5 or WPF?
Business Layer: C#.Net, WCF Services
Data Layer: LINQ, ADO.Net
Database: ?
I need a suggestion on two things
1) Is WPF suitable for all 3 client types? is it easy to make WPF to Web client through xamarine or cardova or any other software alike. if yes pls suggest
2) Which Database service would be suitable for my future extensions to Cloud. And currently which Database can be taken, I will get some simple text data(Unstructured) as input and should process and display as structured in graphical chart way.
Thanks in Advance
|
|
|
|
|
You already posted this in the thread below.
If you want to update your question, edit the message. DO NOT post the update as a new message.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Guys, I am looking for a Design & | Architectural suggestion for my Application which should work for different types of clients: (Thin Client(Browser), Thick Client(WPF), mobile application) and DataBase can extend to Cloud in future
Proposed:
MVC Pattern, Client-Server architecture
Presentation Layer: HTML5 or WPF?
Business Layer: C#.Net, WCF Services
Data Layer: LINQ, ADO.Net
Database: ?
I need a suggestion on two things
1) Is WPF suitable for all 3 client types? is it easy to make WPF to Web client through xamarine or cardova or any other software alike. if yes pls suggest
2) Which Database service would be suitable for my future extensions to Cloud. And currently which Database can be taken, I will get some simple text data(Unstructured) as input and should process and display as structured in graphical chart way.
Thanks in Advance
MYE
|
|
|
|
|
WPF is not going to meet you requirements.
If you need a web UI then forget having a desktop version, there will be little benefit to the user between WPF and a browser solution (and I'm a WPF developer).
Your service should probably be Web API and no WCF.
Depending on your requirements there are lots of good databases to pick from. If it is purely data the a relational database like SQL Server, MariaDB or MySQL will meet your requirements.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thank You Mr. RAH.
I was thinking about WPF Client because My Application will be used by many (more than 90%) by a single client and on a single PC. And A little customers want it as Web So in my view my application should support both Thick and Thin to support all customers
Web API mean REST API? Ok I will check that Thanks.
Please guide me on client and easy transferable DB for future Cloud based application too.
Many Thanks for your response
|
|
|
|
|
Member 8067830 wrote: my application should support both Thick and Thin to support all customers
Your choice but the same client will not support both so you will need to write 2 UIs
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
some plzz brief me what is micro service and how it is different from web service developed with asmx or wcf/web api ?
how to develop a micro service with web api. explain a micro service with a small example.
|
|
|
|
|
|
i got it from your link as follow
Essentially, microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.
normally we develop a web service which can do lots of task and when we break our web service into smaller independent web service which will communicate in each other then it will be called microservice ?
microservice is so easy.......i have a doubt ?
|
|
|
|
|
A "micro-service" (IMO) is something like "get the current local time" or "temperature".
If I got the time AND the temperature, is it still a "micro-service"?
Micro-services may not be as easy as you think: defining what should be in this service; and / or preventing function creep ... going from a snack, to a full-meal deal.
Service bloat?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
not clear the way you explained.
please come with a easy example to define micro service.
|
|
|
|
|
A culture of entitlement.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
This may be viable when using Web API but not for WCF, web api is a URL call and connecting to a WCF service a whole different beast.
I have a monolithic app that incorporates a number of modules all coming from the same WCF, I wish I had broken it into multiple services life may have been quicker if not simpler.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I think "micro-services" are more a concept than a technology.
Microservices
Quote: One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem. (Although this advice isn't ideal, since a good in-process interface is usually not a good service interface.)
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
modified 6-Jun-17 21:53pm.
|
|
|
|
|
After many discussions and information session we finally decided to create our own user database (clients (free and paying), internal users, ...) For this we would create one master database for authentication where each of our tools, websites, services would provide its own authorization.
One of my colleagues is really for using ldap for this, but from what I heard ldap is mainly for internal use and not for external users ("strangers"). I also have the impression ldap is not used often as a master database for customers, companies and even system users (an email address that is read by an application eg). All that data needs to be linked if necessary (eg a person linked to a company, a system email with a person account, ...)
As I don't know ldap very well. Would it be suitable or would you recommend a normal database (oracle, postgresql, sql-server, ...) and more importantly: why?
thanks.
|
|
|
|
|
While I don't know the internals of LDAP I would never use it for external users. You would then be registering external users in your domain, probably not a smart idea.
We use LDAP for all our internal authentication and most of out authorisation and we end up with user group (1000s of them) like APP_CTRY_DEPT_ROLE which we then have to parse in the client app.
It used to be fairly slow but I can't tell any more as our PCs are crippled with enterprise security and I have no idea where to lay the blame.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
You could potentially use ADAM, which would keep your application data separate from your internal AD domain: Active Directory Application Mode[^]
But it would add an extra layer of complexity over a simple database solution. One large product we work with has recently switched from ADAM to SQL for authentication, because they couldn't get ADAM working reliably.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
thanks, but do you recommend for or against ldap, or perhaps it doesn't matter?
|
|
|
|
|
I'd probably be inclined to stick with a normal database, unless an LDAP solution was going to offer some significant benefits. I only tend to use LDAP if I need to talk to an existing AD domain.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
There's nothing wrong with using LDAP for your AAA needs. It's a standardized system with a standardized querying mechanism that is designed to provide RBAC solutions, and is far superior in this role to a database in many different ways. From a security standpoint, it blows a standard database out of the water.
That said, if you don't have anyone on staff that is cozy with handling a domain, you can potentially create some very serious issues by using one (specifically by providing user accounts to anonymous, external users). It is very important that it is actively managed, that containers are properly segmented, and that user accounts have a real validation mechanism backing them (email + reCAPTCHA, etc).
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
I have asked this question in Quick Q&A, but I only got one answer there, and that answer also said something I agree with. That is that the quick answers are not the place for that answer, so I have accepted it, based on the two sample documents and styles it gave, but now I'm asking the same question on a proper board, hopefully to glean more answers/discussion.
I suppose what I'm actually asking for is at best a template, then some suggestions of what areas I must specify.
I have a business spec in terms of user stories together with additional validation rules etc. per story.
I think my spec, which should be divided into front and back-end, for two teams of developers, will be quite large on the basic makeup of the app - how it should be implemented (ASP.NET MVC is a requirement, as that is our standard), and thorough descriptions of the horizontal services. It will then have small appendages of detail for each use case. Am I on the correct track here?
Immanentize the Eschaton!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
