Is it advisable to do all the DB CRUD operations in jsp itself? I feel its better to keep the operations in a Java class itself and forward the results to the jsp so that the jsp remains free from the burden of handling business logic as well.
JSP should be used for presentation purpose only and that recommendation is not recent. Look at this 2003 article :
Don't mix business logic with presentation: For advanced applications,
and when more code is involved, it's important not to mix business
logic with front-end presentation in the same file. Separating
business logic from presentation permits changes to either side
without affecting the other. However, production JSP code should be
limited to front-end presentation.
Of course, thing have evolved and the article might seem a bit outdated but the fundamentals are still true. Many frameworks separating your application in Model View and controller (MVC) exist.
You can have a look at Spring MVC if you want a popular example.
It is indeed better to move all the business logic away from jsp pages to java classes. Even better is to apply mvc pattern (model view control) or use some frameworks that already apply this pattern (struts2, jsf, spring etc.)
Related
I've been trying to find a clear answer to this question for a while but haven't had any luck. I need to know why Struts is tightly coupled? which component of struts makes it tightly coupled.
As this great Mkyong article discusses, what makes Struts tightly coupled is not the presence of something but rather the absence of something. Struts is basically a web UI framework, and it can be compared to Spring MVC. However, unlike Spring, Struts has no out-of-the-box support for dependency injection. As a result, this means that when using Struts your entire code may have to be changed if a given depenency changes. Another way of saying this is that the components you use in Struts are tightly coupled to the framework.
There are two ways of looking at this question:
Struts 1 itself is tightly-coupled, and
Struts 1 is tightly-coupled to the servlet spec
Issue #1
Eliminating this is trivial; use a supported version of Spring, and you have all the DI you need at the application level, e.g., you can inject your services, wire things with AOP, etc.
At the framework level you don't have the same flexibility. You cannot arbitrarily replace Struts 1 framework components. That's why custom request processors and action base classes are the first approach when framework-level functionality is needed–there's nowhere else to put it.
Issue 2
Eliminating issue #2 is less trivial: Struts artifacts all reference servlet spec artifacts, like the HTTP request and response. If you want to abstract that away, e.g., for easier testing, or business logic reuse, you must do so manually.
An example would be to marshal request parameters (e.g., form values) into a domain object or a simple map, and pass that to your domain logic.
Struts 1 was written before DI/IoC was what the cool kids were doing, before strict layer isolation was common, etc. It was written early. It carried that baggage on through the years because backwards compatibility is a thing.
You could argue that the coupling to the servlet spec is good or bad: it's really a matter of where the isolation between business logic and the web app occurs, who is responsible for it, and how do you want to test it.
Unit-testing a Struts 1 action is kind of a PITA. If all it does is handle the web-app-to-business-logic marshalling it's argiable they don't need to be unit tested: the business logic does, but the Struts 1 layer could be tested via an integration test at the web app level. (I'd argue that even makes sense, and I feel much the same way about Struts 2 action testing–but S2 actions are so easy to test (barring heavy interceptor interaction and a few other less-common things) that the differentiation is less important.
I really like all the boilerplate code Spring Data Rest writes for you, but I'd rather have just a 'regular?' REST server without all the HATEOAS stuff. The main reason is that I use Dojo Toolkit on the client side, and all of its widgets and stores are set up such that the json returned is just a straight array of items, without all the links and things like that. Does anyone know how to configure this with java config so that I get all the mvc code written for me, but without all the HATEOAS stuff?
After reading Oliver's comment (which I agree with) and you still want to remove HATEOAS from spring boot.
Add this above the declaration of the class containing your main method:
#SpringBootApplication(exclude = RepositoryRestMvcAutoConfiguration.class)
As pointed out by Zack in the comments, you also need to create a controller which exposes the required REST methods (findAll, save, findById, etc).
So you want REST without the things that make up REST? :) I think trying to alter (read: dumb down) a RESTful server to satisfy a poorly designed client library is a bad start to begin with. But here's the rationale for why hypermedia elements are necessary for this kind of tooling (besides the probably familiar general rationale).
Exposing domain objects to the web has always been seen critically by most of the REST community. Mostly for the reason that the boundaries of a domain object are not necessarily the boundaries you want to give your resources. However, frameworks providing scaffolding functionality (Rails, Grails etc.) have become hugely popular in the last couple of years. So Spring Data REST is trying to address that space but at the same time be a good citizen in terms of restfulness.
So if you start with a plain data model in the first place (objects without to many relationships), only want to read them, there's in fact no need for something like Spring Data REST. The Spring controller you need to write is roughly 10 lines of code on top of a Spring Data repository. When things get more challenging the story gets becomes more intersting:
How do you write a client without hard coding URIs (if it did, it wasn't particularly restful)?
How do you handle relationships between resources? How do you let clients create them, update them etc.?
How does the client discover which query resources are available? How does it find out about the parameters to pass etc.?
If your answers to these questions is: "My client doesn't need that / is not capable of doing that.", then Spring Data REST is probably the wrong library to begin with. What you're basically building is JSON over HTTP, but nothing really restful then. This is totally fine if it serves your purpose, but shoehorning a library with clear design constraints into something arbitrary different (albeit apparently similar) that effectively wants to ignore exactly these design aspects is the wrong approach in the first place.
I am working on my first Grails application, which involves porting over an old struts web appliction. There is a lot of existing functionality, and as I move things over I'm having a really hard time deciding what should go in a service and what should be included directly on the model?
Coming from a background of mostly Ruby on Rails development I feel strongly inclined to put almost everything in the domain class that it's related to. But, with an application as large as the one I'm porting, some classes will end up being thousands upon thousands of lines long.
How do you decide what should go in the domain versus what should go in a service? Are there any established best practices? I've done some looking around, but most people just seem to acknowledge the issue.
In general, the main guideline I follow is:
If a chunk of logic relates to more than one domain class, put it in a service, otherwise it goes in the domain class.
Without more details about what sort of logic you are dealing with, it's hard to go much deeper than that, but here's a few more general thoughts:
For things that relate to view presentation, those go in tag libs (or perhaps services)
For things that deal with figuring out what to send to a view and what view to send it to, that goes in the controllers (or perhaps services)
For things that talk to external entities (ie. the file system, queues, etc.), those go in services
In general, I tend to err on the side of having too many services than having things too lumped together. In the end, it's all about what makes the most sense to you and how you think about the code and how you want to maintain it.
The one thing I would look out for, however, is that there's probably a high level of code duplication in what you are porting over. With Grails being built on Groovy and having access to more powerful programming methods like Closures, it's likely that you can clean up and simplify much of your code.
I personally think it is not only a decision between service and domain class but also plugins or injected code.
Think of the dynamic finders like Book.findAllByName(). It's great that Grails injects them into the domain classes. Otherwise they would have to be copied to each domain class or they would be callable through a service (dynamicFinderService.findAllByName('Book') -argh).
So in my projects, I have quite a few things which I will move to a plugin and inject into the domain classes...
From a Java EE point of view: No logic at all within domain classes. Keep your domain classes as easy and short as possible. Your domain model is the core of your application and must be easy to get.
Grails is developed for dependency injection. All logic which resides in domain class is hard to test, and to too easy to refactor.
You cannot exchange implementations like with services (DI).
You cannot test the code of your domain class easily.
You cannot scale up your system, since your implementations cannot be pooled like services.
My recommendation: Keep every logic in services. Services are easy to test, easy to reuse, easy to maintain, easy to re-configure.
Specific to grails: if you change your domain class, the in-memory-DB will be killed, so you lose your test data, which prevents you from rapid prototyping.
We are migrating our applications to VB.Net 2008 from Classic VB and I need to create a base namespace and business layer. My method of approach is going to be to visit our top BA and identify the common areas of our (Fixed Income) company and try to form a decent inheritence model with as much of the code in generics as possible.
What's everyone's experience of doing this and also as a second part of the question, we are looking at incorporating Web Focus into the OLAP side, how would this affect the design of the corporate namespace and it's derivatives?
I think the best way to begin to create a corporate .NET framework is to begin by harvesting existing code out of current corporate projects. Building a framework from scratch by talking to a BA without writing code for a specific, concrete project might lead you to over design the framework in some areas and totally miss some necessary features in others (as well, it might place artificial constraints on your framework clients for no good reason).
See Fowler's entry on Harvested Framework and this blog post for a more complete explanation.
I'm not familiar with Web Focus but I'm guessing it would affect it in some way, however, if you go with a Harvested Framework, your usage of it in the first few applications you build will shape how you use Web Focus within the framework.
Jereme has it right on the framework. I'll briefly mention something obvious about namespaces.
Always remember what a namespace is for - it's to provide a "space" in which names will live. In particular, it's meant to provide a space small enough that the people creating names within that space will be less likely to produce duplicate or confusing names.
This can only work if the namespaces are organized along patterns of organization, or of domain knowledge. A simple example often used is a pattern of Company.BusinessUnit.Application. The theory is that within the set of developers working on a given application, there is less chance for name duplication. This will not be true for a large application, where you would want to break it further based on layer or area. Similarly, of the business unit is too large, you'll want to break that down.
But in all cases, you're really trying to partition sets of brains, as it's the brains that create the names.
If your application is under VB6 (not VB3) then I strongly recommend that do the redesign to a class hierarchy in VB6 first. The reason for this is that in any conversion you try to preserve the behavior of the old application. Is stretches out the project time to do this and do a redesign at the same time.
By making the design changes in the applications original language first then you are assured that any bugs that result are due to the design not the conversion.
I done three major conversions of our software in the past 20 years; (DOS to VB3) (VB3 to object oriented design in VB6) and (VB6 to VB.NET).
Finally it is straight forward to make a design in VB6 that is ports over to VB.NET readily. The trick is to hide the specific VB6 APIs and constructs behind a interface (graphics, printing, etc)>
When do the conversion I recommend working from the top down. Change over your forms first to .NET which calls the VB6 COM DLLs. Then convert each layer over until you reach the bottom DLLs.
Again, if you try to change the design AND convert to another language for any complex application you will double the conversion time.
I build an app with following layers:
WEB presentation layer
Business Logic Layer - BLL - called from WEB UI through HTTP web services
WindowsService - Runtime - called from BLL through net.pipe
BLL can also be called from 3rd party for integration into other customer's systems.
Let's say that there is an validation error that happens in the Runtime or even BLL. Where would be better to put translations:
in the exception message - means
that we must send UICulture from WEB
layer to lower layers
BLL and Runtime are returning error
codes or custom Exception derived
types and translation is performed
in WEB UI layer
some other method
What is the best practice for supporting multiple languages in SOA architectures ?
EDIT:
I should probably use the term tiers instead of layers.
WEB UI tier is implemented in ASP.NET web forms and will be deployed on server A under IIS.
BLL and Runtime will be deployed on server B but are separated by process boundaries (BLL runs under ASP.NET worker process because of WCF services and Runtime runs as separated windows service process).
My advice for your issues is general because I do not know the specifics of the .NET platform you are working with.
From your question, I see two distinct problems.
You web presentation layer will be language-dependent. It will require custom CSS, fonts, spacing and even custom content. Do not fool yourself that this will not be needed. This is one of the biggest mistakes people make initially when internationalizing web applications. You will need another style for the language. So, if you are using a template approach you can put most of your language content right in the language-dependent template.
From the description of your problem, it sounds like you will also need to handle localized error messages. There is two approaches two this: you can have a language file where you localize when the error is thrown using a resource file solution. Another approach is to have your error messages use a common identifier and parameters and have another layer catch the message and localize it. I myself prefer the former solution since it is simpler.
Also remember that if you are writing your error messages to a log file, that the error messages are in a language that the developers can read. Likewise for errors displayed to users in the GUI, you will want some way for the users to identify the errors to the developers who do not speak the user's language. This could be done by using numbers - I prefer using short keys like DATABASE_ERROR_BAD_QUERY.
The translation should be handled by the presentation layer as it relates to the view. The more context that can be added to the message the better and the business logic might not be aware of the context nor should it be.
An approach that I've used is as follows:
Business logic throws unique, defined
error codes which can be used as keys
into a resource bundle to get a
translated message.
Presentation layer maintains a text
package containing all the error code
translations separate from the
general presentation layer code.
The presentation layer depends on
both the business logic and the text
package.
3rd party clients of the business logic, like a web service,
can choose to include the text
package as a dependency if they want
the standard error code translations.
Otherwise they can handle the error
codes thrown by the business logic on
their own.
I'm not quite sure what is your definition of the WEB UI. If you use the MVC pattern, the Controller would be place to take care of showing the right language version in the UI, while the text itself would be in the View layer. What I didn't understand is what plays the role of the controller in your architecture. Does BLL mean only including processing logic and no communication between UI and Services? If so, then probably the Web UI layer would contain the localization logic.
I would also say that it depends a lot on the technology you use in the project. ASP.NET for example has a built-in localization model that you can use. I'm not saying it should serve as an example, even on the contrary - ASP.NET breaks separation of concerns. But I think this is an issue, which would have very different solutions in different custom architecture models, as in your case.
Based on how your application is structured, you may need internationalization in two locations:
1) Software itself. Menus, Dialogs, Messages, Labels, Reports, etc.
2) Content. Your application when running in more than one language will likely need to handle content in more than one language.
I have had good luck in seperating the management tools and the publishing logic in different layers (so far).
First, consider placing the language translation management and generation logic (resource bundles, etc) in the Business Logic. So, for all your translations, you want a way to quickly sync all data entries as they get added to the system in all languages from a master language (english), and then populate and manage those. So, if you're using resource bundles for example, generate the rb files from a database for all the languages.
Second, publish the language translations logic at the presentation tier. It has more to do with presentation and formatting. You inevitably will run into issues with localization for dates, times, currencies, etc that you can handle pretty well here. You may or may not build your own library to publish these things as the confines, or flexibility of your programming language may or may not allow.
If you can give more details I'm sure there are other insights available from everyone here.
Good Luck!