|
I am working on building a C#.Net winforms project using Entity Framework 5. Currently, I have Model.edmx file on a separate project (DAL) and in my UI layer, I am instantiating Model and accessing my entities, however, I would like to create a proper 3 tier architeture, where separation of concer is adhered to.
Data access layer (where Model.edmx is kept)
Business layer (where Model.edmx is instantiated etc.)
UI layer (all forms code is kept)
Any pointers? Or samples?
|
|
|
|
|
Resonate wrote: Any pointers?
Question is too broad.
People don't write application based on technologies. Rather they write applications to solve problems and use technologies as appropriate to solve the problem at hand.
If this is just a learning experience then there are simple examples which you can google for to learn the idiom. Best practice however doesn't come about from simple examples.
|
|
|
|
|
I'm working on a project that should bring together multiple "services" we offer together into one webpage. These services are basically different (long term) projects that provide different kinds of data. images, videos, "objects"(*), plain text, timeline data, ...
So the main architecture would be to write an interface that would serve the project's webpage, but also could be reused for other projects (so not only that webpage).
The current discussion is whether to use JSON, XML or web services. I'm looking for advantages/disadvantages for all three.
Personally I would opt for webservices. type-safe, most flexible and especially, no parsing  (in the sense that the IDE will interpret the wsdl for you). There is a learning curve for non-programmers and apparently php and web services don't mix well I'm told. (Most people here use php to do something code-wise). They use Python as well and I know that works and java is also used often. (I personally don't know php)
XML seems like a good alternative since you can create validation schemes (and make it more or less type-safe) and there are many libraries that can handle it reasonably well. It is a very verbose format.
JSON is very lightweight and easy understandable, but is less type-safe and no validation scheme to my knowledge.
So what is your thought on this? Any good read-ups on pro's and cons out there would also help.
thanks!
(*) Objects with attributes, a structured set of data belonging together.
|
|
|
|
|
Can all your prospective clients consume your transport format, if yes then use JSON, the sheer verbosity of XML can kill your network/server. That schema comes at a very high cost if you are transporting high volume or complex data.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
IIS can perform dynamic data compression; and XML can compress to less than 10% of its original size.
I talked one sports analysis vendor out of upgrading their transport layer by showing the reduction in bandwidth that compressing their XML game files would accomplish (which ranged up to several hundred megabytes uncompressed).
There is no generalization when it comes to transporting XML versus JSON in this case.
|
|
|
|
|
And if they aren't using IIS? Okay, that's slightly facetious as the other major web servers all offer similar functionality but it's always worth remembering that, where the poster hasn't specified a technology stack, that you can't assume a particular feature is available.
This space for rent
|
|
|
|
|
Certainly.
But that's why I said "IIS"; and not "some web servers".
(One Google also told me Apache does compression ... Any others worth considering? WebSphere?).
I could have also argued that "protocols" (XML and JSON) are not the same as "web services"; and it's not like you pick "one of these".
And also about how I could use compressed "payloads" (which I already deal with when communicating with web services that supply graphics).
(It's not like I was going on about something totally unrelated to the question; like, "SQL injection" ... again).
|
|
|
|
|
I would vote for WSDL (SOAP?) based services...and PHP has no problem whatsoever to work with that...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: PHP has no problem whatsoever to work with that
I was indeed surprised when told. WSDL would be my first choice as well, but the people here don't like it for some reason (not standard, unlogical, verbose, ... ). I'm trying to convince them this is the way to go so I need arguments 
|
|
|
|
|
Hi,
I got the feeling, that new programming languages spread out of the earth like gras... or at least did so a while ago.
I want to question the need of new languages here. Why don't we have just a couple of basic rules and build the "languages" on top of it like add-ons. So if you want the have a keyword X, you can just implement it as an add-on to the compiler.
Why should that be necessary?
I think if you want to start a project and would have a free choice over the language you use, you might get in a situation like this:
- I want to use language X, but it's library is not that big
- I want to use Java, but it's too heavy
- I want to use x because it hast feature y
- I need lightweight stuff, so I should use X, but it lacks features, syntactic sugar, already implemented patterns.
I just came to think of that, because I'm usually using c++, which forces me to do a lot of writing for things, that could be automated (which by now, can only be done by the SDE).
On the other hand I also use Java, which lacks the constant-iation of the this-pointer or typedefs (as known from c++).
So then, the compiler would not be a blackbox anymore and everybody can create their own programming environment which suits best to the solution that's going to be created.
what do you think about this idea?
regards
|
|
|
|
|
 the idea is best but hard for implement but not for a programmer
|
|
|
|
|
I think most people would download every plugin they can find. Now imagine every plugin creating separate versions that may or may not work well together.
Source code isn't going to change once compiled; I do not see the advantage over loading a library and executing the containing code.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
You could change the syntax at places that are handy to you.
I remember one article of ChristianNeumanns.He talks about functions, that should tell in their head, if they can return NULL (like Java does with exception). Because of that, he wrote a totally new language.
Now, no matter how good his language is, if you can't use it, you can't have the features. But if you could load that "language feature palette" into your c++,java,smalltalk,c#,..., you can have the features in your current environment  (?)
|
|
|
|
|
D4rkTrick wrote: He talks about functions, that should tell in their head, if
they can return NULL (like Java does with exception). Because of that, he wrote
a totally new language.
Sounds like overkill; and when encoding too much information in a name you get more unreadable code.
My user-code could adhere to the same principle, I do not see what value the change to the language has (is it the language, or rather the framework? Sounds more like the latter one where somebody thinks his naming is 'better')
I also do not see how this would work in practice; it may change code unintentionally whenever someone downloads a new 'keyword'. How would that affect code that's already compiled?
I think the amount of actual keywords is limited, and the bulk of extensions will be done in usercode, using plugins. As for language-extensibility, I'm happy with the current .NET runtime; new keywords are defined (!) for each version, and they are consistent - with the added option to define your own language for the runtime, and the ability to extend the syntactic sugar using either a plugin for your IDE, or adding 'aspects'
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote: I also do not see how this would work in practice; it may change code unintentionally whenever someone downloads a new 'keyword'. How would that affect code that's already compiled?
oh, yeh, I actually didn't think of that! The portability would indeed suffer very much by adding such a feature.
...Also you made .NET a little bit more interesting for me
|
|
|
|
|
Thanks 
|
|
|
|
|
D4rkTrick wrote: I got the feeling, that new programming languages spread out of the earth like gras
Rather certain that that is a fact. Use the following to watch the ones that actually make it above the noise come and then go.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html[^]
And an example of extremism
https://en.wikipedia.org/wiki/Whitespace_%28programming_language%29[^]
D4rkTrick wrote: So if you want the have a keyword X, you can just implement it as an add-on to the compiler.
To a large extent there have already been languages like that. "Forth" is just that. There was some other language sponsored by the US government (i believe) years ago that did something simpler.
There is however a great deal of difference between whether something is possible and whether you should do it.
D4rkTrick wrote: you might get in a situation like this:
Not me. I have learned that all of that is subjective.
D4rkTrick wrote: which forces me to do a lot of writing for things, that could be automated
Learn how to do code generation. You write a program that takes in input source and outputs code.
HOWEVER, that said, do not think that even most code can be created that way. At some point the very reason programmers are needed is due to the variable nature of what is needed. And writing a code generator that can handle that is not only impossible but even attempting to do so produces code in the generator that is a mess.
D4rkTrick wrote: So then, the compiler would not be a blackbox anymore
You might enjoy taking some college level courses specifically addressing compiler design.
|
|
|
|
|
So funny that a couple of years later (now) people are using babel, webpack, typescript, which is essentially exactly what I was thinking at that time
|
|
|
|
|
I'm relatively new to web applications development, specially when it comes to frontend, but as I understood, a typical frontend would have a php/jsp layer that calls the backend to generate dynamic pages.
Now we're designing a new site, and a colleague of mine insists on not having that layer. He wants the pages to have html and JS, that will then directly invoke the backend. This, of course, means having the backend services publicly available, which I'm not particularly comfortable with.
Is this architecture somehow common? Can it be considered to follow MVC?
|
|
|
|
|
I never even touched PHP nor Java, the 'typical' website at our company is written in MVC. Still, any public service that is available from the internet will be used by someone you don't know. May be a good way to test its robustness, but I wouldn't recommend having a public webservice without any authentication that can be used to delete data
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I am creating a Java web service that is receiving input requests in XML format. The web service's function is to parse the XML initial request and send it's own post request to a third party organization which does a look-up for the request and if available they send a response back in XML format to the web service for processing. If the response does find the data in the look-up the information it sends back as XML and is parsed by the web service then saved as a .pdf file. Once the .pdf file is created the web service packages a response XML message and along with the identifying information a link to the .pdf is part of the message sent back to the calling client. Now, if the search for the information is not found a XML message is sent back to the client indication the third party did not have the information ready with a status as pending. For all of the requests for the third party information the web service will create a folder on the server with a XML status file and if the .pdf file is created it will be in this folder too.
Now comes the tricky part of the design. There is another application located on the same server that needs to be running in a loop that and every 30 second it needs to call the web service on it's own and if the server folder created by each new request does not contain the .pdf that program will make the web service call to retry the initial call and see if third party does now responds with the XML message that contains the valid information so it can create the .pdf and send a message back to the original client.
Now, if I am using a tomcat server what type of application should I create that does the 30 second looping? The server does have a MySQL database. How should I have the 30 second looping application communicate with the web service? Finally, if the looping application does make a successful call to the web service what is the best way to cause a trigger from the looping application to make the web service send the successful response to the original calling client?
Finally, if the looping application does make a successful call to the web service what is the best way to cause a trigger from the looping application to make the web service send the successful response to the original calling client? One note is that the 30 second loop must scan the new request folder tree and retry for any of the requests that have not succeeded.
|
|
|
|
|
I have given this problem a lot of thought and I think I might have a solution. The site does have an IIS server as part of the application. I think I could create another asp .net web service that runs on that site and have it handle the 30 timing process. What I think might work is that I use a 30 second sleep then cycle through the process again. Does anyone see any problems with doing this? Any problems with resources or having a separate web service running like a different thread in the same application?
|
|
|
|
|
Just make your "looper" another "client" application that sends asynchronous requests to whatever server for status and retry requests. Use a timer, service, sleep loop, thread with UI, whatever. Looper can run from anywhere, including the server.
|
|
|
|
|
So what your saying is don't use a web service for this but create another web application for the looping code. Is this correct? If this is the case
how would I get the original main web service that handles the main client I/O to communicate with the new web application? I know I would have no problem sending service requests to the main web service but don't know how requests would go the other way. I guess I could always use the database to go from the main web service to the web application. Does this sound like the best way to go?
|
|
|
|
|
I suggested a "client" (NOT web) application: console; Windows forms; WPF; service; Java whatever. Something more manageable and flexible than a "web app".
If you want to know more about how "servers talk to clients", refer to "asynchronous callbacks".
You've already established a work-flow; all you're trying to do is introduce a retry mechanism. Step back and think about this "client" as a "monitor" / observer that submits retry requests; that's all.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
