|
Reread the first paragraph of the post, the OP states there are issues with the existing system.
It curls my toes thinking about trying to convert such a large codebase and betting it will work.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
It was more a rhetorical response to your generalization.
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
|
|
|
|
|
sx2008 wrote: They think if everything is translated to C# their productivity will rise and they have a lot of time to improve the code
LOL...
No really LOL LOL LOL
|
|
|
|
|
Has this at the end worked? I think not, except adapting ported forms with implementing special logic manually.
|
|
|
|
|
In my workplace, we have an intranet website developed internally that we use for CRM. The data of our clients are shown there (MS SQL server is used as a backend to store data). The site has a limited search functionality at the moment (it'll try to match the text you type in one of the 3 fields that are indexed -company, staff contact, and director name).
I'm trying to find info about what would be the easiest method to implement a more sophisticated search (ideally that makes use of AI), like the one implemented by Google or Amazon on their website. It doesn't have to be so sophisticated, anything better than what I described above would do it. Ideally, the search should be able to guess what you're looking for based on your role, your portfolio of clients, and previous searches. It would be great if it could understand what you mean (i.e search query 'song la la la' that returns as result 'ATC -All around the world' on youtube. It would be great to implement vocal search as well.
But again it doesn't have to be that complex. Any info on where to look or which resources are readily available would be greatly appreciated. Do you know if there are (and what would be the best) search engines/AI libraries/API that are open source and that would fit this purpose? If this is not the right place to ask, on which other website or forum do you think should I ask for?
Thank you in advance
modified 17-Jun-21 12:07pm.
|
|
|
|
|
Maria Delpiano wrote: If this is not the right place to ask
Probably is the best place
Maria Delpiano wrote: what would be the easiest method to implement
Better be careful with that approach.
What is the size of your database now? And do you have actual reasonable data on the expected growth rate?
Otherwise this is what will happen. You will come up with something that works ok with 20,000 rows (across 5 tables) and then it completely falls over with 20 million rows (perhaps by locking up the database for a minute every time someone does the search.)
Maria Delpiano wrote: Any info on where to look or which resources are readily available would be greatly appreciated.
Following in google seems to return quite a bit of info.
predictive search algorithm
Maria Delpiano wrote: (ideally that makes use of AI),...It would be great if it could understand what you mean (i.e search query 'song la la la' that returns as result 'ATC -All around the world' on youtube. It would be great to implement vocal search as well.
Since you presumably have nothing now I would suggest just ignoring all of those ideas currently.
Maria Delpiano wrote: your portfolio of clients,
To me that is something you need to be very careful with. If you have user A with a set of clients X, I suspect you do not want anything associated with X showing up for user B (whose clients Y are different.)
And because of that restriction alone is it possible that you can only build your data based on one user with no sharing at all? Can you insure that a query by user A, if exposed to user B, even without the client name would not be a problem?
|
|
|
|
|
I would assume he already has client isolation already in his current, simple, search.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Hello,
It's same for 'inputs',
get if the type is good, and so the length,
for a enhanced search : history ( by client ?? ) or 'workers background' ( so filtering choice and Db feedback too.
If 'A' really go A*
if 'B' then 'go NOT 'A*'
modified 23-Aug-21 21:01pm.
|
|
|
|
|
How do you desired which of the architectural pattern to work with?
|
|
|
|
|
I reject the premise of the question.
|
|
|
|
|
Why rejecting what you should be able to deal with?
|
|
|
|
|
Experience and knowledge and what you have learnt about the business requirements.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
What if this is your startup and idea, and you've yet to write the business requirement? Your experience level is coming from a lot of books and youtube videos you have read and watch.
|
|
|
|
|
Tabah Baridule wrote: you've yet to write the business requirement
Then why are you thinking about architecture patterns. Get you business plan and requirements sorted and THEN start looking into what platform(s) you will service and the different patterns that will meet your requirements.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
A pattern is where you're repeating the same block of code; it is now a pattern; your pattern. The fact that no one has used it before, or named it, makes no difference.
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
|
|
|
|
|
|
Many patterns, such as those in the GoF book, aren't "architectural". They're more tactical, although they can help to make an architecture better.
Jim Coplien, who was well-known in the C++ world, got involved with patterns early on. Later, he said that there was too much focus on patterns. The emphasis needs to be on encapsulation, polymorphism, and inheritance. Patterns are the exception when those things, by themselves, don't produce loosely coupled code.
To understand a pattern, you need to have seen what code looked like before the pattern was applied, and after. Then, when you write or find code that looks like the "before" code, you'll know how the pattern can improve it. That's usually how a pattern gets used. How code evolves to satisfy its specifications is what determines which patterns are used; it is wrong to start out by saying which patterns will be used before you have a good sense of the high-level design.
|
|
|
|
|
 Thank you, permit me to share this as a tweet.
|
|
|
|
|
|
The most correct thing previous commenters posted is that you need to handle business requirements first.
The other correct thing is that GoF patterns are mostly tactical.
Given that in my answer I'll assume is that architectural patterns are monolith, microservices, CQRS etc.
With that said I'd start from monolith application since microservices bring a lot of overhead that you might not need until you've pitched a PoC to some investors or might not need it at all if you're not going to have a team of sufficient size or your application won't endure high loads.
Then your application will evolve according to your business requirements and also to a fact that your understanding of business will evolve too.
Say you'll discover that your business problem contains of multiple subdomains. Then you can handle them via vertical slices.
Or you may need to handle spikes in application load. Then you might need to extract some microservices.
In general, my advice is to start with the simplest solution unless you're encounter requirements to act otherwise.
|
|
|
|
|
|
They're primitives; like having bones; not really something you can obsolete.
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 guess the writer is correct in that specific scenario, but he has not addressed all the others.
|
|
|
|
|
- "it's not flexible", not if you consider adding an extra case to be a Big Deal, but the alternative is adding an entire new class.
- Even if you are of the opinion that creating new classes is somehow easier than creating new cases, then spend a little time thinking about what would happen when the function signature of that virtual function is changed, or if something about the API used by the subclasses to implement themselves changes. This has the annoying property that the fix you're about to write is highly non-local, you'd have to "hunt down" all the places that need to change - in the best case they correspond to compile errors.
- If a requirement is broken into N cases, but the code is spread out non-locally over N classes, your code does not look like the requirement which makes it harder to check whether it matches.
- "it's not SOLID", maybe, but SOLID is subjective and overrated.
- "horrific", let's not even talk about it.
- The presented "better way" presupposes that we have a convenient instance of the "class that represents a particular reason". How did we get that? Chances are that there's a switch hiding in a factory pattern or something. Moving the problem. And if there is some pattern such as
new AddressChanged().Update(), how about we don't wrap it in a class and just call a method that does that. - Article forgets to point out that in the first place the only domain that was considered is the business logic domain. Even if it makes sense there (which I don't agree with either), it won't make sense anywhere else. There's no way
Math.Min would have its if replaced by polymorphism.
|
|
|
|
|
swampwiz wrote: This article purports
First of course writers have different goals than programmers. Always keep that in mind when reading postings on the web.
From the link
"New requirements come along. Who would have thought? You were so sure nothing would happen"
Wrong, wrong, wrong.
Attempting to write code in case something might happen is a sure way to lead to code that is difficult to maintain.
If you already have requirements, even if it is just from a whiteboard, then your design and implementation should, of course, take that into account. But if you are claiming that you are writing your code to make it easy to add requirements that are unknown then you are at least ignorant of the challenges of maintaining legacy code. Especially if your claim is for something that might happen far in the future.
What actually ends up happening with that hubris is that code must be maintained for years or decades despite the fact that it serves no purpose. The complexity actually makes it harder, not easier, to add new features because it is more complex.
The best you can do now for such future possibilities is to write code that is easy to understand. And to make it clear how the code that you wrote now meets the requirements that you have now. Then that programmer 10 years from now who must add a feature that is actually needed then, will at least be able to understand what your code actually is doing and very likely needs to continue to do even with the new feature in place.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
