I have been looking for a sample structure of a project when you have, for instance, Java/Spring backend and a front end like Angular2.
My first thought was that they will go in two separate top-level folders, like
src/
ui/
This way I would be treating both as their own apps, like they actually feel (since the logic in angular is going to be different than what is happening at the backend).
But then I thought about the fact that this will make it harder, when browsing the back end, to find what is actually a front-end representation of the given package. So then I thought about using a structure like
src/main/java
src/main/javascript
And then follow Java-like-package folder structure. This would make it quite easier to see where one thing stands in the UI and what controller/service is responsible for replying to its requests.
However, I can't seem to wrap my mind around which of the two is going to be better for a project going forward. Is there any article/guide that you can recommend me for situations like this (hybrid technologies and project structure, or perhaps this is a specific stack that I'm not aware of and already has some defined good-practices).
I followed the approach from JHipster, where the Angular2-Structure is under
src/main/webapp/app
The advantage is, that you can bundle multiple frontend-technologies in webapp beneath angular, and keep everything seperated but in one project. I think this makes it robust until a high level of compexity.
Related
I'm currently learning myself the Codeigniter framework. I want to create a project that will have a front-end (which will be used by users) and a back-end (which would be used by administrators).
I have looked through different articles, all of them suggest using HMVC to separate the public and admin controllers/views. I have also considered to create two separate projects, one for the public and one for the admin, both using the same database.
I have tried to do research on which one of the methods mentioned above would be the best solution for a potentially large project, but could not come up with any sustainable answer.
Is it possible that two separate CodeIgniter projects can access and use the same database simultaneously?
Edit:
The client project would mostly just query the database for results, whereas the admin project would be full CRUD.
If indeed creating multiple projects would be the recommended way to go, the admin project would be running on a sub-domain i.e admin.example.com whilst the client project would be running on example.com
It is valid to use any of the approaches you mention. It is a matter of personal preference (read: opinion). I have used each singly and in combination with more or less the same outcome. I have settled on using none of the above. Instead, I use a single project, no HMVC, no subdomains, standard CI file structure. I feel keeping it simple ultimately makes it easier to build and maintain. YMMV.
What separates the public-users from admin-users is authentication and authorization (A&A). Nobody gets into an admin controller without the proper login credentials and permissions. You're going to need A&A anyway to keep the public from accidentally discovering the admin area. IMO, a "special" file structure and subdomains actually make implementing A&A harder.
Depending on your deadline for this project you might want to look at using CodeIgniter Version 4. It's a thoroughly modern revamp of the framework. It is still in beta test mode, but I've found it to be quite stable. They are working hard to get to the release version. There is no published release date yet, but all indications are it will be sooner rather than later.
The answer as to how to configure CI is really dependent on your needs and what you feel is best. There is no right answer or "acceptable" way of doing things in this regard.
When I first started with Codeigniter, I had just a sub-folder for backend controllers called admin as well as an Admin base/core controller that all admin classes extended rather than CI_Controller. Models/views can be similarly organized in to sub-folders. This was a perfectly acceptable solution in my opinion for small-scale applications.
I moved in to HMVC and found that it really isn't that much different in terms of keeping them both separate. Although you can easily drag-and-drop modules from different projects so long as they are decoupled, you'll still have to jump through hoops to get front/back ends separate. I believe I used this is a starting point: https://github.com/jmtolibas/HMVC-CI3-with-Separate-Backend-and-Frontend
In terms of what you mentioned, having 2 separate projects wouldn't necessarily be a bad idea. You could even share the same system folder with a modification in index.php regarding the system path. Multiple database connections shouldn't be an issue.
So basically, all 3 approach will work, it is up to you to determine which one you like working with the most.
If you want my opinion, I would use Laravel or Lumen on any new project, and separation of front/back end is rather easy with packages, namespacing, .etc.
There is a project that is built using JSF with Spring Integration.
See https://www.tutorialspoint.com/jsf/jsf_spring_integration.htm to get an idea.
JSP is used for the html templates. Managed beans (part of JSF) make use of Spring beans as a managed property, which in turn drive business logic. The goal is to rip apart this project and split it into a RESTful service and Angular front end.
What is the best way to do this without re-writing everything. Which components can I get rid of, and which components can be re-used? If I use Spring Boot for building the REST API, can I re-use the Spring beans?
Edit: I am new to most of these technologies.
Exposing your domain model through REST should be relatively straight forward using Spring/JPA, whatever. You should learn about DTOs and especially as it relates to problems about "Lazy Initialization" under Hibernate/JPA/Spring Data, etc.
Secondarily understand the concept of views into the domain model. E.g., shipping looks at the database differently than marketing. Same database, different "facades" or business layers with different set of DTOs.
Conceptually, reproducing a JSF front end in Angular is something that is both "the same thing" and "completely different" at the same time. The key difference, IMHO, will be the JavaScript concepts and paradigms underlying Angular/React/Vue or whatever you want to use on the Front End.
Consider that an AngularJS/React/Vue front end might be better off running on top of node.js in a separate container or server, and might have different databases that it accesses on its own such as loyalty points or currency conversion, etc. Don't be afraid to let the frontend folks "be" the application instead of the backend folks. On the backend, try not to lose information. For example, if a customer adds 3 items, then changes 1, then places the order, that's 3 separate pieces of information, not 1 order. This is important for business analytics and customer service, which are business facing services as opposed to client facing services.
As a Java developer I tend to feel Angular/JS developers do a completely different and non-overlapping job than me. I feel the same way towards HTML/CSS folks. As such, I don't recommend you try being both, you will stretch yourself too thin. However, a good working knowledge on a smaller project, such as you are suggesting, is certainly useful.
Welcome to SO. Your post will probably be closed/ignored for being to broad, etc. Very specific questions and answers are what this site is about. GL.
I'm going to build my first REST app via Laravel and a client side framework which I'm not sure yet (probably React or Vue.js).
I did some research about how should I build my app, and unfortunately it got me even more confused.
I've come to a conclusion that I can build my app in 2 ways:
Build the app in the same project. However, without Laravel Blade.
Separate the App to 2 projects (Front and Back).
On the one hand, the pros of building the app on the same project:
Grants me the option to use Laravel Mix.
Laravel offers out of the box Vue support.
On the other hand, the pros of building the app separated from Front to Back:
Each side has its own single responsibility and can be refactored easily.
As I heard it from my friends, it's more convenient (even tho for me it sounds too complex).
I wanted to know what is the most popular way to build a RESTful app when Laravel is being part of it. Is there another way of what I mentioned?
Personally,
I like to keep them apart because it's easier to maintain. Yes, you have to keep track of 2 different projects/folders/repositories but they are pieces of the same cake.
Scaffolding an API in Laravel is very easy and simple. I assume you already know how to do that. You are worried about loosing the advantages offered by Laravel Mix, but believe me you are loosing nothing.
Since your preference is on Angular, just clone any seed project repository with everything setup. e.g:
1. AngularJS: https://github.com/angular/angular-seed
2. Angular 2: https://github.com/mgechev/angular-seed
As you can see, these seed projects already have all the build tools you need and now things seem actually easier. That's what frameworks are made for.
Now imagine later you want to add a mobile app to the stack. You don't even need to change a single thing. Your API already runs independently of the frontend and vice versa.
Question is opinion based... So here is my opinionated answer.
TLDR: For speed of development and arguably more satisfaction, build as one project. Don't overcomplicate unnecessarily too early. When project gets big enough, and starts to generate you some money, then think about splitting the projects - you will know when it is time.
The Laravel Ecosystem is just great for small, medium and even large applications.
Laravel gives you a resources folder, where you can put all your Javascript & front-end assets. You have Envoy to deploy your application and write your deployment scripts. You have mix to build your assets. You don't have to use mix - you could write your own gulp/webpack/grunt etc...
By keeping together as one project, you are able to use the same IDE project for both front-end and backend work, yet keep separation of concerns because all backend code is completely separated from front-end code. You can tweak the payloads being sent from angular, and tweak how the payloads are handled in PHP api nice and easy so you only need 1 ide and one browser and a terminal client.
The nicest thing about keeping the project together, is that assuming you are using VCS (git) and you really should be, then your front and back-end will always be in-sync with each other. Otherwise, you need to manage & coordinate deployments of your front-end and backend code.
When your application gets big enough, it won't take long to separate the projects as the frontend and backend should be already extremely loosely coupled.
Just think of all the added layers of complexity that you are introducing to your application. When you deploy a change to your REST API, you will probably need to also deploy a change to your angular application. What version of the angular app is compatible with what version of the API? If you have a team of devs, working on specific projects, then this complexity pays off - but most teams have processes in place to manage, synchronise & automate deployments.
I think you should go with 2 projects. I would.
I will give an example using complexity rate of growth. It is just from my own experience. (X means amount of features, Y means how complex they are to implement)
With a single project, it is super simple at first. No communication with the server, no hard stuff, everything is tangled. Then nearing the end, it starts to get harder and harder to create more features/pages because everything is tangled.
Or as a function:
But if you start with 2 projects, sure, it will be harder at first (communication, synchronisation, whatever) but the rate of growth for complexity will not be as high. Everything has it's own responsibility, everything does what it needs to do. Tests are simpler, expansion is simpler, refactoring is simpler, and you can complete the project with ease.
Or as a function:
Clearly, from the graphs above, you can infer that the rate of growth for a single project is much slower. (And of course, not actual numbers, I did not measure anything or tracked such projects, this is just out of my own experience)
I’m developing a part of an application, named A. The application I want to plug my DLL into, called application B is in vb 6, and my code is in vb.net. (Application B will in time be converted to vb.net) My main question i, how is the best way for me to organize my code (application A)?
I want to split application A into layers (Service, Business, Data access), so it will be easy to integrate application A into B when B is converted to vb.net. I also want to learn about all the topics like layered architecture, patterns, inversion of dependency, entity framework and so on. Although my application (A) is small I want to organize my code in the best way.
The application I’m working with (A) is using web services for authenticating users and for sending schema to an organization. The user of application B is selecting a menu point in application B and then some functions in my application A is called.
In application A I have an auto generated schema class from an xsd schema. I fill this schema object with data and serialize the object to a memory string (is it a good solution to use memory string, I don’t have to save the data yet), wrap the xml inside a CDATA block and return the CDATA block as a string and assign the CDATA block to a string property of a web service.
I am also using Entity framework for database communication (to learn how this is done for the future work with application B). I have two entities in my .edmx, User and Payer.
I also want to use the repository pattern (is this a good choice?) to make a façade between the DAL and the BLL.
My application has functions for GeneratingSchema (filling the schema object with data), GetSchemaContent, GetSchemaInformation, GenerateCDATABlock, WriteToTextFile, MemoryStreamToString, EncryptData and some functions that uses web services, like SendShema, AuthenticateUser, GetAvalibelServises and so on.
I’m not sure where I should put it all?
I think I have to have some Interfaces like IRepository, ISchema (contract for the auto generated schema class, how can I do this?) ICryptoManager, IFileManager and so on, and classes that implements the interfaces.
My DAL will be the Entity framework. And I want a repository façade in my BLL (IRepository, UserRepository, PayerRepository) and classes for management (like the classes I have mention above) holding functions like WriteToFile, EncryptData …..
Is this a good solution (do I need a service layer, all my GUI is in application B) and how can I organize my layers, interfaces, classes an functions in Visual Studio?
Thanks in advance.
This is one heck of a question, thought I might try to chip away at a few parts for you so there's less for the next guy to answer...
For application B (VB6) to call application/assemblies A, I'm going to assume you're exposing the relevant parts of App A as COM Components, using ComVisibleAttributes and similar, much like described in this artcle. I only know of one other way (WCF over COM) but I've never tried it myself.
Splitting your solution(s) into various tiers and layers is a very subjective/debatable topic, and will always come down to a combination of personal preference, business requirements, time available, etc. However, regardless of the depth of your tiers and layers, it is good to understand the how and the why.
To get you started, here's a couple articles:
Wikipedia's general overview on "Multitier Architectures"
MSDN's very own "Building an N-Tier Application in .Net"
Inversion of Control is also a very good pattern to get into right now, with ever increasing (and brilliant!) resources becoming available to the .Net platform, it's definitely worth infesting some time to learn.
Although I haven't explored the full extent of IoC, I do love dependency injection(a type of IoC if I understand correctly though people seem to muddle the IoC/DI terms quite a lot). My personal preference for DI right now is the open source Ninject project, which has plenty of resources online and a reasonable wiki section talking you through the various aspects.
There are many more takes on DI and IoC, so I don't want to even attempt to provide you a comprehensive list for fear of being flamed for missing out somebody's favourite. Just have a search, see which you like the look of and have a play with it. Make sure to try a couple if you have the time.
Again, the Repository Pattern - often complemented well by the Unit of Work Pattern are also great topics to mull over for hours. I've seen a lot of good examples out on the inter-webs, and as many bad examples. My only advice here is to try it for yourself... see what works for you, develop a version of the patterns that suits you best and try to keep things consistent for maintainability.
For organising all these tiers and layers in VS, I recommend trying to keep all your independent tiers/layers in their own Solution Folders (r-click the Solution, Add New Solution Folder), or in some cases (larger projects) there own solutions and preferably an automated build service to update dependent projects with up to date assemblies as required. Again, a broad subject and totally down to personal preference. Just keep an eye out when designing your application for potential upcoming Circular References.
So, I'm afraid that doesn't even slightly answer your question, but hopefully provides you with some resources to check out and a few hours of reading.
Good luck!
Having used some PHP frameworks such as Codeigniter and Kohana for some smaller sites, I'm starting to wonder if MVC is still applicable for larger projects and, if so, what precautions need to be taken to maintain clean clode. What practices do the larger sites use in order to prevent this? Does Amazon's or Flickr's code use MVC or some variant of it? Is there a guide that, given a certain problem, shows you how best to implement MVC for large projects?
-- Tangent --
On a current project using Kohana, I started to question what role my models should have. Often times, a model can only describe a small part of an object that I'm trying to build. I.e., need an object for a User, so I extract my user from the Users table using my Users_Model. But each user also has several items in their inventory, so I need to also use the Users_Inventory_Model. But, each inventory item also has other tables associated with it, and so on, until I find that building up a single User in my controller has required me to access several models. Now, imagine doing this in many different controllers and suddenly I find myself with messy and redundant code and very fat controllers.
This led me to think that maybe I should have libraries which handle most of the grunt work. That way, I could have a Users library and let it load all of my pertinent user data and run most of the logic such as updating, deleting, etc. Is this the way most MVC projects evolve? Letting libraries do most of the interaction with the models, while the controllers call the libraries and prepare the data for the views? Anyway, this is just one of the questions I've had about MVC, which I haven't been able to find an answer to online.
In fact, it's for big projects where all these MVPs and MVCs really shine. All software design patterns are "created" (besides establishing common vocabulary) to deal with complexity of software. Thus, used properly, MVC will be of great help to you in big projects.
Contrast with small apps, which can be hacked together with mouse-only approach, but are a nightmare to support since there's no proper separation nor they're SOLID enough.