Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have:
UI layer
Business Layer
Data access layer
Common code layer
When I need to, for example, perform string manipulation that is unique to the application and isn’t a candidate for common code. Where would you place this function?
Currently I have it in the controller but is does not feel right.
I would move it out of the controller but keep it within the MVC application, as it sounds like presentation logic. It could be a helper or maybe an extension method.
I would recommend you to make Common.UI, which will store all common things for Pressentation Layer in a separate project. In the future it will help you to switch between different pressentation layers and use same common features.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm new to Symfony and I was really surprised when I saw that very important parts of program logic are "hidden" in the annotations. Or actually in PHP comments. I understand, these annotations are used by the libraries, but is not it a bad solution overall - couldn't it be made differently? What is the logic behind that? From my prospective they make the code hard to understand, they are not processed by atom (or can I install some plugin for this?..), and it's overall strange idea. No?)
All That configuration can be stored in php/xml/yml files.
From my experience the idea of annotation is very convenient.
For example, you look at controller , and you see route (link to call controller action), data passed ( Parameter Converter).
If it is done right, you have all the important data in one place, just above your code.
Processing annotation by IDE it's a different story.
Check if there is any atom plugin for this , or change IDE that can handle this.
Personally, i'm using phpstrom , and i don't have any issue with annotations
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Currently, I'm implementing a Robot framework using the "Page object model".
Kindly let me know if there is another better model.
I would say that the answer depends on what is your system under test (SUT) and how large your test code will be. IMO, page object model is a good choice for SUTs that are systems with many views and you will have a large test automation code base.
If the code base is small, you don't have to think that much about maintainability and code re-usability.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
So I was wondering the other day, where to put private methods, that do some dirty work in Web API.
I need to extract certain things from JSON, methods will do the job and return some result.
So where do I keep those methods?
do I need to write a separate library (dll)?
or just do this stuff in the controller?
I don’t think it can have a single answer – it depends on…
If you think this private method can be reused from some other controller in future, better to have a separate class, if you think it can be reused from separate modules (not just from controllers), a separate class library project can be the answer.
But if you consider this private method is designed to support for a specific action of a controller, you can write within controller, before taking any decision a few more parameters to be considered like unit testability or slimness of API etc.
You should keep your controller thin as much as possible. You can move logic code to service package, for example JSONService class or JSONLib.
I often use following layout:
controller/
lib/
service/
model/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What's the best approach?
1- Create multiple projects:
2- Create a single project:
I'd suggest you take a look at Spring's Project Sagan. It's the source code for their current website (http://spring.io). While they used a multi-module approach, it wasn't divided as you are suggesting. They really just pulled out some client work and kept the rest in a single module.
This site was written by the Spring team the way they would use their own tools and released as a reference application to answer questions just like this. I encourage you to take a look here: https://github.com/spring-io/sagan.
The point is to ask yourself what is the point in separation. If you are planning to run them in different containers on different servers, then it makes sense. If it is a large project, it makes sense to separate.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am asking this as there are many ways of populating a data control (like GridView and FormsView) and it can get overwhelming for a new developer.
What's the best approach?
Should data source controls (like SqlDataSource and ObjectDataSource) be avoided altogether?
I'd say SqlDataSource is not very appropiated for n-layered applications (except n = 1) since it talks directly to sql server.
On the other hand, ObjectDataSource is a perfectly acceptable option since allows you to call methods from classes on any of the layers the web layer has access to. It won't restrict your layers architecture at all.