|
You could try searching Google, your local library, bookshops ...
|
|
|
|
|
What architecture?
You start off with a 3-tier system, select a DBMS (relational or whatever) for the back end, choose HTML or any such crap for the front-end and there is your architecture.
Is there anything else?
Welcome to the world of suburban tract-home of computer architecture!
|
|
|
|
|
You should definitely read this Patterns of Enterprise Application Architecture[^]
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
My aim of finally year to do big and nice project that can work in on web and desktop.
In desktop when no connection application can work without any problem and when connection come just it update the action performed.
So I Think it possible but i no title for that project "Please help me for give title"
|
|
|
|
|
You first need to decide what actions, inputs and outputs the application will contain. The title is trivial, you could even name it after your cat.
|
|
|
|
|
My project i want to help my country (government) and record the information on government
|
|
|
|
|
|
You could go totally off the wall and call it "Doofus and the chocolate fireguard".
Starting with a title is a terrible idea - you need to work out what you want your application to do first, and then work out what it's called.
|
|
|
|
|
You can give more information about title
|
|
|
|
|
"My recipes".
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
You explained what the app does technically, which sounds like a generic data-application. Based on your first post, you want to edit/share data - like cooking-recipies. I'd recommend a name that gives a hint as to which problem it solves for the user.
When in doubt, call it "Henk" and rename it later
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Well, that depends on what kind of person you are, and the personality of your teacher/professor.
In your situation I would name it something like:
- Yet To Be Named
- Function over Form
- The Unnamed Application
- [Insert name here]
or
- MyTIB (acronym) = My Teacher Is the Best
The best way to name something is either using an acronym:
- YP3 or YPPP = Your Personal Podcast Player
- FREE = Financial Records Enterprise Edition
- STEEL = Software To Extract and Evaluate Lists
- WINDS = Windows and Internet Networked Development Software
or just describe your software:
- Free Website Creator
- Your Budget Personal Edition
- Personal Notes and Reminders
- Your Personal PodCast Player
There are also tons of name generators out the on the web, and you could also look up in a dictionary and find a word like "Avalanche", that is just a word and does nothing except identifying your application
Good luck!
|
|
|
|
|
I had this question earlier on what would I consider as a complex architecture and just responded with a blank stare as I was confounded.
On my own opinion, I would like to think that architectures need to be complex, or rather even if it is "complex", if it was designed properly, it should still be straightforward and easily understandable.
I do have my doubts, so please be gentle with the pitchforks.
What do you guys think?
|
|
|
|
|
Member 4411225 wrote: What do you guys think? About what?
|
|
|
|
|
You can not learn a design pattern simply by running into one that you never seen. Same goes doubly so for architecture. You will not learn CSLA.NET simply by looking at it and going "Yes, I see now".
We aim to keep things as simple as possible, as having things simple makes stuff easier to maintain. But no, you do not recognize a "good" architecture simply by it being straightforward or easily understandable; source-code is not an instruction manual, does not show the bare bones and comes with a lot of noisy details not related to the architecture but to the problems that the application solved for its domain.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
NickPace wrote: IMHO anything that does not follow the SOLID principles is probably overly
complex Hence, "most of the code in existence today".
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Hence, "most of the code in existence today".
I would say that within the bounds of error and statistical variation that "most" is actually "all" in any meaningful sense of the word.
|
|
|
|
|
Member 4411225 wrote: I would like to think that architectures need to be complex, or rather even if it is "complex", if it was designed properly, it should still be straightforward and easily understandable.
I would like to think that unicorns were real but reality keeps getting the way.
Humans are limited. Humans are fallible, even the ones that are really good.
Complex systems and some point do not become amenable to being easily broken down.
And finally of course businesses are not willing to wait much less spend infinite sums of money waiting for perfect solutions. Even presuming they knew what the wanted in the first place.
Consequently systems are messes. And more complexity means more mess.
The only goal can be to insure that is not any more messy than it needs to be. Within limits.
|
|
|
|
|
Architecture is similar to design but at a larger scale. And like design, is about managing the complexity of a software system (or multiple software systems that are interacting with one another).
There isn't anything inherently complex about architecture, except that few people have practical experience of it. Designing and architecting large enterprise applications requires a deep understanding of architecture patterns. For this I would recommend Martin Fowler's book on Architecture Patterns.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I remember once having an argument with a "Systems Architect" who said I and my team were just bricklayers who built a system from his plans. I replied that we were more like structural engineers who could point out to him that the house he had designed using expensive straw would collapse at the merest visit from a little naughty wolf, never mind a big bad one. He did not like being told this.
=========================================================
I'm an optoholic - my glass is always half full of vodka.
=========================================================
|
|
|
|
|
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I prefer simpler. It has the potential for less security holes, maintentance, and performance problems. But this all has to do with what the application is and the objective.
Blah blah blah... say your prays...
|
|
|
|
|
"Keep Code Left" (KCL) is the name I've given to a coding style I believe improves code readability and maintainability in almost any procedural language. I've been coding for many (many) years, and reviewing code as a dev manager for much of that time.
Over the years I've come to the conclusion that programmers are abusing if statements by using the then clause to contain the meat of a method, rather than to contain the exception cases. This is most egregiously demonstrated by short examples found in many internet articles which are written like this:
private void Page_Load(object sender, System.EventArgs e)
{
if (!IsPostBack)
{
someControl.val = 1;
}
}
The fundamental premise of KCL is that the "meat" of the method should be as un-indented as possible, and indented code is for cases which are errors or uninteresting due to starting data conditions. Most often, these exception cases end in a return statement as there is no more work to be done for that case. This leads to a simple rewrite whose implications are far-reaching (really!).
private void Page_Load(object sender, System.EventArgs e)
{
if (IsPostBack)
return;
someControl.val = 1;
}
Almost by definition this reduces the complexity of the code and increases the maintainability. If your job is to manage any significant body of code, then surely these two goals are front and center for you, each and every working day?
So what about those cockroaches else statements? By following these two points, I've found it is possible to remove over 50% of the else statements from much of the code I read; this reduces or eliminates the indentation, and even in some cases exposes bugs just by this simple refactoring (don't believe me? Try it!).
Code like this:
public IIdentity Identity {
get
{
if (this._identities.Count > 0)
return this._identities[0];
else
return null;
}
}
becomes this:
public IIdentity Identity {
get
{
if (this._identities.Count <= 0)
return null;
return this._identities[0];
}
}
The more lines of code there are in a method, the clearer the code becomes.
I've created a presentation on this topic which builds and expands on these ideas. I've delivered it at a couple of user groups over the past several months, and it's remarkable how many people have approached me at other technical gatherings since then to let me know how much they think the ideas presented have helped improve their code. This has encouraged me to share with the wider community.
Although the presentation is more fun given "live", with interactive Q&A featuring many code samples and discussion, I'd like to share it here, and solicit feedback and perhaps start a lively online discussion.
http://www.slideshare.net/MichaelMickAndrew/keep-code-left-10-1114
|
|
|
|