Currently I'm working on a webapp that has a structure roughly like this:
model
user
robot
service
user
robot
web
controller
user
robot
I'm noticing a lot of redundancy in this structure. Is there any way that I could create a project structure that is less redundant?
The main idea behind folders in a project is to encourage separation of concerns. Each folder should group code into separate functionalities.
Your folder structure seems fine, but I would suggest changing the name of the files so that you know exactly what you're dealing with.
Perhaps more like:
model
user
robot
service
userService
robotService
web
userController
robotController
This way you know immediately that:
model files show structure of entities but no functions or logic
services deal with business logic only
controllers deal with API interfaces
Related
I am currently using Telosys to help me generate Spring JPA Entity Classes from an existing database. So far, I could generate the repository, service, provider directory by using java7-persistence-spring-data-jpa template, but not the entity. Is it possible to generate these entities if you are using the database model (not the DSL model)?
I already figured it out. Looks like each templates serve different purposes in Telosys. If you encounter the same problem with mine, try switching it to this template: java-jpa-entities-T330.
You can explore more java templates here in their github.
As described at the end of this post https://modeling-languages.com/telosys-tools-the-concept-of-lightweight-model-for-code-generation/ each "bundle of templates" is designed to generate a subpart of the final application.
It's a way to manage separately the differents concerns of a project (REST controllers, domain classes, persitence, unit tests, etc)
From a maintenance and deployment standpoint, does it make sense to have one Web API 2 project with many (30+) controllers, or 30+ micro Web API 2 project with one controller each?
I started down the path of having them all in a single project whose structure would look like this:
Comapany.Project.Api (solution)
AccountController
OrderController
InventoryController
//many more here
AddressController
I've come to think this will be problematic when deploying since we just use a file system publish that deletes all files prior to publish. If I make a change to the orderController and have to deploy during the day to production, I will bring down many other services.
I'm about to rework my project structure to something like this:
Company.Project (solution)
Company.Project.AccountApi
Comapny.Project.OrderApi
Company.Project.InventoryApi
//many more here
Company.Project.AddressApi
Then I would have a
Company.Project.Core
This core project would contain some shared code like extension methods, custom exceptions, actionFilters, etc.
I know the answer to this could be very subjective. However, I'm looking for concrete reasons to choose one solution structure over the other. Thanks
I stick with all controllers in one project. I also tend to like to use a single Web API controller per domain / tier / whatever you do to logically break down your application into more manageable pieces so that the amount of controllers can be mitigated.
I've documented my practices on my GitHub Wiki.
The client I'm working for has a CMS written in Yii. Currently a part of their business is customizing the CMS to meet the specific needs of each customer. About 90% of the code is reused, essentially by copying and pasting from one directory to another. While I've been working on this project, I've had to merge changes in to the shared codebase several times.
All, or most, of these sites are hosted on the same server, and it would seem that it would make more sense to have a single login, that changed what features we showed based on the login. In some case that means overriding whole or partial views (eg, the _form.php might change from customer to customer) including the controller and model. Most of the time, it means adding a new controller for a bit of functionality written just for that client.
I've read about having both a front and backend site here: http://www.yiiframework.com/wiki/63/organize-directories-for-applications-with-front-end-and-back-end-using-webapplicationend-behavior but that doesn't seem to be the right fit (I don't want everyone coming to a different start php file, for instance)
Ideally, I'd have users log in, and get assigned a site id, which will filter data in the shared MVC objects, and will add in the ones specifically for them, or override the ones where necessary
Intuitively it seems like something like this would make sense:
Shared controllers go here:
/protected/controllers
Overrides and additions for client1 go here:
/protected/controllers/client1
or:
/protected/client1/controllers
But I'm not sure how to get Yii to do this in the most efficient and easy to manage way. Is this something that's going to work with Yii, or am I breaking it in ways unintended? If it will work, what's the best way to accomplish it so that it's clear to me six months from now, or some random developer who replaces me?
Do you know RBAM ?
With Role Based access you can profile your application in more-or-less granular way
I need to create a few classes and would like some help on where this would go in the YII Framework. I know if I create a Model, it must go in the "models" directory. And by the same logic I know where "views", "controllers" etc would go. However, where would the following be placed in my web application:
A class that contains a variety of "number" functions such as currency conversion, metric conversions etc?
A class that interacts with a REST API? (It interacts with the database)
Any tips?
To get started with adding custom classeses on YII you can check below link.
http://www.yiiframework.com/wiki/165/understanding-autoloading-helper-classes-and-helper-functions/
Hope it'll help you to start.
You can find an example here, it is pretty detailed in my opinion:
The directory structure of the Yii project site
Usually you can use any PHP class in within Yii. You can place it in the models folder (alongside the Yii generated models) and access them directly like so:
$myclass = new MyClass;
$myclass->methodname;
Alternatively (or if you run into any issues), you have can place it anywhere in your directory structure and include it in the main index.php (in the root) like so:
$myclass = dirname(__FILE__).'/myclass.php';
require_once($myclass);
We have planned to start an e commerce project using Stripes + Hibernate.
Please let me know if it is good to have admin & user part in same project or two separate ones.
If it is a single project , how do i separate admin side code & user code.
for eg: if i have admin actions in com.ecommerce.adminactions pacakge and user actions in com.ecommerce.useractions package should i use dynamicmappingfilter to direct admin request to com.ecommerce.adminactions and user request to com.ecommerce.useractions ?
-http://myecommerce.com/admin/* - > should always go to com.ecommerce.adminactions
-http://myecommerce.com/ -> should go to com.ecommerce.useractions
or
Should i use #urlbinding(/admin/st.action) in each class (Hard code).
The requirement is they need multistore concept.
Please let me know your thoughts on this.Your thoughts & suggestions will be helpful
Thanks
The Stripes framework does not really influence decisions on how you should organize you're project, or how you should organize your IDE project structure, or even Java package structure or URL structure.
One or more project
Unless you have many developers, keep it all in a single project.
Package structure
A package structure should organize you're Java classes so that you put classes that are logically related (as defined by your architecture!) is in the same package. For example: com.ecommerce.action.admin and com.ecommerce.action.. See also: Properly package your Java classes
URL structure
Typically you want you're URL structure to reflect the logical structure of your website (not the same as your technical structure). To accomplish this, you should not rely on the default URL's but use #UrlBinding. With the annotation you do not hard code links, as all generated links will automatically use the UrlBinding pattern.
Multi store concept
For a multi store concept, you will need to build logic in your application for distinguishing between the different shops. For example by adding a shop id to your URL parameters. Or more sophisticated by detecting the (sub)domain name used and map that to a shop id (You can implement this by using an interceptor).