I am starting with a project in Spring-mvc which basically is made up of 3 parts
1) Frontend
2) Backend (admin)
3) Web service
What would be best way to organize these parts so that I can reuse the domain and DAO layer objects wherever I can and at the same time keep the packages separate (so as to avoid class names such as FrontendCategoryController and BackendCategoryController in the same package) ?
Also would it be a good idea to have common config and the pom.xml file for all these parts ?
As of now I have started with the project structure generated by maven as per the webapp archetype
Edit:
One way I am thinking of doing this is -
myapp
-- src
-- main
--java
--resources
-- backend
--java
-- resources
-- webservice
-- java
-- resources
in all java directories, the package names will be same
Would this be a correct approach
Thanks
First of all, depicted approach that misuses Maven directory structure looks really bad.
You say that you want to avoid long class names such as FrontendCategoryController and BackendCategoryController. It looks like your design violates "Package by feature, not layer" rule. You can create separate packages for your subapplications, so that long class names wouldn't be needed. Common classes used by all subapplications can be placed in yet another package.
Alternative approach would be to create separate Maven projects for different subapplications, but it looks like you don't want it.
Related
Say I'm going to create few microservices: Alpha, Beta, Gamma.
In terms of Application structure using older Symfony version like 2, I'd create a bundle for each service, but bundles are no longer recommended in Symfony 4. So... Should I create separate repositories for every service or still create a bundles in a one App?
If you have different microservices, as in different applications, you will not need bundles. You can keep them in different repositories, but a common practice is to use a so called mono-repository. As the name suggests, with a mono-repository you keep all of the projects in a single repository. This has the benefit that changes spanning all projects can be done more easily and in sync. The drawback is that it requires more effort when managing and might cause additional overhead when building and deploying as it will not be easy to see which service has changed so must likely you rebuild all of them. There are a few books and presentations on mono-repositories you might want to check out. In short, Symfony does not restrict how you manage your services. You can have a single repository for all projects or multiple repositories.
If you want to serve all "services" through the same application, even without bundles, you can do so by using namespaces to separate the logic, e.g. for controllers:
my_app
- src
- Controller
- Alpha
- IndexController
- Beta
- IndexController
This should work out of the Box with the default configuration and even if you deviate you can make things like argument resolvers work by just pointing the configuration to the correct folder. Obviously this will require you to make sure that code is not shared between services should you ever want to extract them into their own application. There are some static code analyis tools that help you with keeping your architecture clean, i.e. make sure Alpha does not use code from Gamma and vice versa.
If you want to separate the apps more clearly by doing something like this:
my_app
- src
- AlphaApp
- ...
- BetaApp
- ...
You can still do that but it will require more manual work and the recipes will not work anymore, requiring you to do manual changes to most configurations and moving around files. How to do it depends on whether you want a shared kernel or a separate kernel for each service, but if you go that route I recommend keeping separate projects in the same repository, as it will probably yield cleaner results and be less work.
You can still create bundles in symfony4 though its not recommended by best practices. see https://symfony.com/doc/current/best_practices/creating-the-project.html
My code is divided into websites, one for each module (in TFS). Also, I have some application level code (like loginpage.aspx, webconfig.xml, Configuration.xml, Common.css, Logo.gif, masterpage.js, mainmaster.master, mainmaster.master.cs, etc) which is common for all module level websites. Is there a way I can reference the common application level files in each module level website. I want to avoid multiple copies of the application level code, by using a reference or some other mechanism.
The best way to handle this kind of shared code is in your solution-structure, so TFS can stay straightforward and your common code is not duplicated localy either.
So try to make the common-code shared by creating a project that provide baseclasses where the other projcets (the websites) can build on.
I have an play application with the following structure:
-mainApp
-app
- controllers
- models
- services
- views
-test
-modules
...
And i have a subproject in the modules folder.
Now I want to use the class Test.class in the "services"-folder in a class of a submodule (called "listadmin"). I thought it's possible with the import:
import services.Test;
But this doesn't work. I get the error (if I compile) that the system don't know the package service.
How do i import a class of the main-project in a subproject?
Thanks for help!
I think the only way you can do that is to have the sub-project dependOn the main project. Of course, the main project also will dependOn the subproject, so I'm not sure what you gain by creating a sub-project. I'm having a similar issue. I'm trying to separate my big project into self-contained smaller projects, but I need some info from the big project (the main template file so my views fit in with the rest of the application, a default URL to send pages to when users don't have permission to see pages, etc.) If I can't find that someone has already asked this question, I'm going to, so keep an eye out.
Hi i want to know what is meant by modules in a project??how they are classified and how many modules we can have in a project?can anyone explain with simple examples??What modules we can have in a typical online shopping website?
In .net context I believe one can draw 2 meanings not sure what specific you are looking for.
One is modular programming by following design principles like "Separation of concerns", "Single Responsibility", "loose coupling". This means divide you code into classes based on these principles and further group these classes again based on these principles into modules.
In ASP.NET or C# or in general we create class library projects and use them across the entire project. Like all the logging functionality is put in some classes and these classes are include in an class library project which can be called "Logging module". Whenever you need logging in any of the project you can include this module and use the functionality.
Some examples:
Web module for HTTP requests ( The WebApp)
Repository and Data access Layer modules. (DAL code)
Models module containing all the business entities.
WebService modules for integrating with other apps.
Logging for debugging and problem identification
Infrastructure/Utility modules for utility like functionalities and
application configuration.
Business logic modules.
Transaction gateway module.
Other way to define module in .net is they are PE files and I believe they have extension .netmodule which contain Metadata but they do not contain the assembly manifest. To use a module you have to create a PE file with the necessary assembly manifest.
Create a module:
csc /t:module ufo.cs
Create assembly using the module:
csc /t:library /addmodule:ufo.netmodule /out:airvehicles.dll helicopter.cs
Above 2 commands are from this link
The module is an external code that you plugin on your site and runs in order to do some actions.
(source: codeguru.com)
We make and use modules to have the ability to share the actions of the module with others with out giving the source code, and vice versa, we use modules from other that we do not have access to the source code. Or we can simple use module for have the ability so simplify our code and remove it easy if we do not need it.
We can have as modules as we like, but each module place extra overhead on our code - after all is need to make more thinks there.
More about modules: http://www.codeguru.com/csharp/.net/net_asp/article.php/c19389/HTTP-Handlers-and-HTTP-Modules-in-ASPNET.htm
How to create module: http://support.microsoft.com/kb/307996
I am a total newbie on Prism. I have been getting to understand a lot from questions on SO and from various Blogs. I am using latest build – V2
I want some explanations on things that may be pretty easy things for you guys but it’s just not getting into my brains (small one for that).
Instead of doing it all right the first time , for which I have spent more than two weeks looking at various blogs, webcast …., I thought to start a project and learn. The amount of information on those hundreds of sites was overwhelming and difficult to digest.
Currently my project is setup like this
Shell -- Menu Module- ViewModel - - -> Menu Service -- -- > Menu Repository --- Data
All are in different assembly
MyShell --- MenuModule ---MyServices -- Myrepository
Shell is required to reference modules ( thought I am sure I can add it using string) later on .
ViewModel has a reference to View - Can live with it for now
View Model requires to use menu service and menu service uses repository
All are built with constructor injection. I have it working now by having module reference MyService and Myrepository projects and then registering types at module level.
But this does not feel good. I don’t want to hard reference any projects. If we are referencing projects why use IoC. In MenuModule.cs ( which is in the root of module) I can register views with unity container
I think I am getting a feel that the answer to this one may lie in the first question
Is Configuration file the answer/
Should I use configuration file for
true decoupling?
If (somehow) we can
register types from code, should we
register types at module level ( I
don’t want to have hard reference to projects)
I need to know the
Interfaces in advance so do you
recommend separate assembly for just
Interfaces?
Bear with me if the questions sound real stupid
You don't need a configuration file for true decoupling. All you need is to register your types in your shell's bootstrapper. I usually break up my projects and refs like this.
Contract Assembly
(Contains only a few simple types and interfaces)
Referenced by:
Shell
Modules
Shell
(Contains concrete implementations of interfaces defined in Contract assembly)
Referenced by:
No one
Modules
(Declares dependencies on interfaces defined in Contracts assembly, for instance IMenuRegistry)
Referenced by:
No one (I use a Directory Module to search for modules in a directory)
Here's a sample project I put together. In this sample I reference the module from the shell for simplicity's sake, but you can remove that reference and use a directory module catalog to load the compiled module at runtime:
http://dl.getdropbox.com/u/376992/CAGMenus.zip
Hope this helps,
Anderson
You're definitely on the right track. Use the configuration file to register your types, and put the interfaces in a separate assembly.