Design and Architecture

Design & | Architectural Solution for my Application which should work for different types of clients: (Thin Client(Browser), Thick Client(WPF), mobile application)

12-Jun-17 1:58

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

Member 80678309-Jun-17 4:56

Member 8067830

9-Jun-17 4:56

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

[REPOST] Design & | Architectural Solution for my Application which should work for different types of clients: (Thin Client(Browser), Thick Client(WPF), mobile application)

Richard Deeming9-Jun-17 5:23

Software Design solution for Different Presentations - Thin Client(Browser), Thick Client(WPF), 3rd Party(SOA) application

9-Jun-17 5:23

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

Member 80678309-Jun-17 0:47

Member 8067830

9-Jun-17 0:47

MYE

Re: Software Design solution for Different Presentations - Thin Client(Browser), Thick Client(WPF), 3rd Party(SOA) application

Mycroft Holmes9-Jun-17 23:10

Re: Software Design solution for Different Presentations - Thin Client(Browser), Thick Client(WPF), 3rd Party(SOA) application

9-Jun-17 23:10

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

Member 806783011-Jun-17 19:56

Member 8067830

11-Jun-17 19:56

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

Re: Software Design solution for Different Presentations - Thin Client(Browser), Thick Client(WPF), 3rd Party(SOA) application

Mycroft Holmes11-Jun-17 23:42

Can we develop micro service with web api

11-Jun-17 23:42

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

Mou_kol1-Jun-17 23:37

Mou_kol

1-Jun-17 23:37

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.

micro service - Google Search[^]

Richard MacCutchan1-Jun-17 23:40

Richard MacCutchan

1-Jun-17 23:40

Mou_kol2-Jun-17 0:04

Mou_kol

2-Jun-17 0:04

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 ?

Gerry Schmitz2-Jun-17 4:44

2-Jun-17 4:44

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

Mou_kol5-Jun-17 22:28

Mou_kol

5-Jun-17 22:28

not clear the way you explained.

please come with a easy example to define micro service.

Gerry Schmitz6-Jun-17 3:50

6-Jun-17 3:50

A culture of entitlement.

"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal

Mycroft Holmes6-Jun-17 14:44

6-Jun-17 14:44

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

Gerry Schmitz6-Jun-17 15:08

6-Jun-17 15:08

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.

user database

V.29-May-17 21:11

29-May-17 21:11

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.

(MQOTD rules and previous solutions)

Mycroft Holmes29-May-17 22:37

29-May-17 22:37

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

Richard Deeming30-May-17 1:33

30-May-17 1:33

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

V.30-May-17 1:36

30-May-17 1:36

thanks, but do you recommend for or against ldap, or perhaps it doesn't matter?

(MQOTD rules and previous solutions)

Richard Deeming30-May-17 1:46

30-May-17 1:46

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

How to write a 'system spec' for an app based on a business spec.

Nathan Minier30-May-17 2:02

Nathan Minier

30-May-17 2:02

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

Brady Kelly21-May-17 22:09

Brady Kelly

21-May-17 22:09

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!

Re: How to write a 'system spec' for an app based on a business spec.

Gerry Schmitz22-May-17 3:57