My question is next - how you organize code-base of your application when it have a lot of complex code?
I start learn Symfony 4 framework. Before I developed applications using Yii 1.1 and Yii 2 frameworks. In projects that was built around this frameworks code divided by modules for better organization and maintenance. This way of code organization is encouraged on all forums dedicated for Yii frameworks.
In Symfony world closest analog of Yii modules is bundles. As I understand, after reading related articles and docs, they really was used for such code organization, but they were developed not exactly for this purpose. For Symfony 4 authors recommend build bundle-less applications and at this point I really confused.
Search for answers on my questing give me nothing. Some advice to group classes under namespaces (sub folders) in controllers, templates, entities, etc, but I feel that this is not a right way since views, controllers, services and other classes will be scattered across project.
I know that one right answer for this question does not exist, but anyway I curious about how this problem is solved in Symfony world.
Nothing is stopping you from just ignoring the current official recommendation and splitting your web app into multiple Flex Bundles. That's what I'd do because as it stands now, what they are recommending is essentially an antipattern.
Related
I've been developing in ASP.NET for 1,5 years. (I used first Web Forms for a year and when I get a new project I decided to learn MVC) Now I am about changing job where they want me to develop in J2EE or SpringMVC. How long does it take to get practice in those (not to get pro just to reach a level to make good quality software)? I think that those web frameworks are very similar to the web frameworks of .NET I used.
Am I think right? Is there somebody who have changed from .NET to Java (or vice versa)?
I think of it as there are two main things you need to understand in order to build good quality software:
The general principles of the area you're working in
The specific details of the technology you're using at the time.
In the web-space, the principles of ASP.net and the concept of MVC is pretty similar to the concept of the SpringMVC. There are loads of Model-View-* type frameworks, which basically have the same concepts behind them.
You'll have the same set of concerns building an application in Java as you did in ASP.NET - Separate business logic from presentation, connect to a database, appropriate level of logging, security, error management, authentication, etc. etc.
The concepts you learned using ASP.NET you'll be able to re-use in the Java space.
The specifics of how you utilise them will be different (although often, surprisingly similar - compare nunit with junit, Hibernate with nHibernate). It'll take a little while to get to grips with how SpringMVC works and how it's configured, with how to build and deploy a Java project, with the particular structure of the libraries.
But in the end it's the same principles.
Also, particularly in the web space, all of the HTML, CSS, javascript, browser compatibility, user experience is identical. How you include that stuff in your project varies a little, but the actual markup that gets sent to the browser, and the challenges in making it right are exactly the same.
Doing something new like this will help too, because you'll see where the similarities are, and where the differences are. It might help highlight why they're similar.
It would be really good if you got on a project with some experienced Java people on it. They'll have the basics down and be able to structure it so that most of the big risks are managed, so you can get to grips with the technologies and differences to start off with.
Most really good developers can develop in several languages. I recommend you add Java to your list.
Couple of month ago I got a legacy project written on Sf2. I fixed some bugs, and added some new functionality, but still i feel that it was made a little bit clumsy. Well, maybe not just a little :) So, I have a number of questions, how things really should be done in Sf2.
The first thing which is bothering me, is that the Application is separated on Frontend and Backend bundles. The're standing on the same model, and for example entity Book can be seen from FrontendBundle and edited from BackendBundle. In some way this is producing a confusion of abstractions. So my question is - is it right, or wrong, and if wrong how it should be done in appropriate way?
Bundles are components in symfony2 that provides a functionality to your app. The frontend and backend approach has changed in symfony2, the bundles are used instead.
For example, you can create a BookBundle, and put all the functionality regarding to books in that bundle, adding, updating etc. And by configuring the routes, you can redirect all the requests about the book to that bundle.
The main point is, the frontend and the backend about the books resides in same bundle, and only in that bundle(with controllers and entities and repositories and views etc.).
This is the intended usage in symfony2.
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 9 years ago.
Improve this question
I am in the process of architecting an application. It will be a large, enterprise class web application. Thousands of users could upload files, search large number of blog entries with chat functionality and such. It will also have mobile interface. It should be highly testable, scalable and flexible.
I have narrowed it down to three environments: pure play ASP.NET, pure play DotNetNuke (DNN) and a combination of ASP.NET and DNN. To keep this very brief, here are some 'for' and 'against' on each of the options:
ASP.NET:
for: highly scalable, supports patterns like MVC, testable, consistent architecture.
against: long development time.
DotNetNuke:
for: short development time, large number of existing functional modules and skins.
against: architecture is sealed, can't support MVC, unit testing is difficult, inconsistent modules/skins, potential upgrade issues, user experience is inconsistent due to disparate modules from different vendors, poor documentation.
So, the questions are: what do you think? Has anyone switched from DNN to ASP.NET (and, vice versa)? Have you objectively evaluated these two and what did you choose?
Highly appreciate your help. Thanks.
henry.
DNN is ASP.NET, just with a lot of the work done for you.
Also, please remember that just because raw ASP.NET has the potential to be more scalable, doesn't mean that you are actually going to built it to be more scalable. Or that you will built it well in the first place.
It comes down to a trade off between control and resouces/talent. If you have many very talented developers (like, top-10% talent), a lot of time, clearly defined requirements for your site, and consumers who will be patient while you build out the infrastruture, by all means go with raw ASP.NET.
However, if you need to build it quickly and need to be flexible, or you have limited development resources, you might have to sacrifice some of that control and unit testing and potential performance (again, the "potential" part is key here).
Based on what you are looking for, I'd recommend you go with a platform like DNN, or a million other ones line SiteFinity or Umbraco or Orchard or something like that (some of them like Umbraco give you MVC too). It gives you a lot of the infrastructure and plumbing common among a lot of sites, probably done better than you are going to do it, so that you can focus your resources on the truly unique aspects of your application.
Just stay away from SharePoint. It's evil.
I've built raw ASP.NET sites for really customized applications, which was good because I didn't need a lot of plumbing and wanted really unique funcitonality through the site. But then I've built social networking sites with DNN, which worked well because it had packaged components for blogs and forums and chat and all that stuff, plus allowed for easy skinning. I designed another application for a customer that they wanted to have a lot of custom functionality, but they also wanted to updated a lot of content and internatalized it, so we used a Umbraco for that. And right now I have a ASP.NET app that works great, but I want to add in some social features, so I'm going plug in a Umbraco or DNN site that integrates with it to host the more common social components.
I would definitely recommend DNN based on your very limited list of needed features. You can always build a custom module to meet your exact needs or modify an existing open source module as needed. You can use the MVP approach in your module development to improve the testability.
Have you considered the Umbraco CMS? It is built on .Net (v5 is MVC3). It is open source and a very robust and well supported application. It has been used for the asp.net site for example.
It has a very short development time, many modules, extremely flexible and I find it very easy to extend. For example, I rolled my own workflow, event driven publishing and have created multiple custom administration sections for managing bespoke functionality external to Umbraco.
You can use XSLT, Usercontrols or Razor to create template modules.
It has a fantastic community too.
Can we use Drupal as a framework for larger application? Is it suitable for developing big application in its framework, or is there any limitation of it?
I want to use Drupal as a framework in my application. Is it worth?
If you are looking for a development-framework, Drupal is probably not the right choice. If you are looking for a suite to build websites, Drupal is probably the right tool.
People often tell that Drupal is a CMF, where the F stands for Framework, but in reality, Drupal is simply a flexible CMS.
On a high level, web application framework are split into two categories: the MVC and the CMS. Model View Controller being what most people call a framework. CMS being simply a flexible CMS with application-development abilities.
In practice, what Drupal lacks is:
Proper architecture. Most things in Drupal, evolved organically; which causes inconsistency, unexpected behaviour and unexpected barriers. Not saying that Drupal is not build up properly: just saying it has not been architectured: designed as a whole.
Principle of least surprise. Many frameworks allow skilled developers to create sites in a few hours. With Drupal you must gain a lot of experience and best-practices before you can be confident to roll out websites on planning.
MVC. Drupal has a distinct database-layer and a theme(view) layer, but they are unconventional, and often misused. And certainly not after a structural pattern.
unopinionated behaviour: a framework can force certain methodologies, libraries or even encourage certain behaviour, but it should not have hardcoded/none-overridable defaults that dicate your end-product. Or, in English: Drupals core has many defaults that dictate how you are going to set up, layout and structure your website, regardless of your (clients') needs or wishes. Modules or addons come even momre often with behaviour and often looks built-in and/or hardcoded.
DRY, don't repeat yourself: Drupal heavily depends on repeating oneself. Its entire theme-system depends on copying pieces of code into custom files and changing tidbits. Its form-override system requires copying large parts of the default form into custom modules and changing the parts that one wants modified.
Many of these lackings are the main cause for delay and budget-slips, as seen in my +10years Drupal-experience. Where the unopinionated behaviour part has proven the most nasty one to most of the projects I was involved in. Apparent simple features or ideas prove to take up large parts of the entire budget; Tiny details eating away development-weeks; that last 20% taking not just 80% of the effort, but sometimes 300%.
Besides that, Drupal does not follow OO patterns, which (according to the general consensus) is a bad thing. There is no inheritance, not DRY-practice, no object-relation-mapper*) and no unittesting-practice.**).
This might all sound negative, but in reality, people manage to build nice Drupalsites despite all these "downsides". That is because they adhere to the defaults by Drupal mostly (standard where possible, addons where changes wanted, custom development when no other option is left).
*) In fact there is; in Drupal 7, PDO was introduced, but is not (yet?) used as ORM much/at all.
**) In fact: all of core and many contributions have tests, but these are integration tests and a rare unit-test. Integration-tests (DrupalWebTest) install a clean Drupal-codebase+database for each single test. Your average core-testsuite taking over 8 hours to run is not an exception. TDD is simply not (yet) possible.
EDIT Reading into your examples: Drupal is particularly bad in the area of "form wizards", though it has seen improvement in Drupal 7. Another notable lack, in Drupal, is a proper, programmable workflowing system. There are several modules that enhance or replace the simple workflow-system in core, but they are not easy, nor efficient (development-effort-wise) to program against. It sounds like the main features you want, are amoungst the most underdeveloped areas in Drupal
This really depends on the needs of your application. Drupal, while flexible and extensible, is first a CMS and comes loaded with features which may or may not be desired for a web application. But if out-the-box or with additional modules it provide a large matches for the more classic web application features (ie. user management, content management, plugin system, theme layer, etc.), Drupal provides a great framework to avoid re-inventing the wheel (or dependencies on third party/less-mature framework plugins).
Drupal as a steeper learning curve compared to most framework. As a framework, Drupal is build and designed to for the CMS it is. Historically, Drupal puts almost everything in database. The situation is now better with the generalization of exportables and tools like the Features module. Also, unlike most framework Drupal does not use MVC and is mostly not object oriented.
Yes! You can use it as a framework. You'd want to be happy with some of the core APIs like the menu, node and probably the form API. The menu router and access control are quite good.
I've worked on a couple Drupal sites that didn't quite work because the core requirements had little to do with a CMS. Drupal is very flexible but it most suited to content management. You can of course use it as some satellite CMS for some other application. Drupal can also be used for service driven architecture.
If you want to scale up big, you might consider a framework that places more importance on testing and test driven practices. Drupal is a late adopter of these practices and is not mature in this area. It's something that I find frustrating especially on large sites where regression error becomes an issue. Consider something like Ruby on Rails if this is of interest to you.
Good luck!
Note to self: Why would I wish someone luck on a software project? ... interesting.
Drupal 8 change a lot.
- It is OOP
- Using Composer
- Have good cache mechanism in core
- RESTful in core
So now it is easy can be used as framework for any app. At end web all ways have content. E-commerce have content. And so on.
I am trying to think about a web application development framework for our product development. I want to build an ASP.NET application which has many sub-modules in it. My requirements are like:
The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
Each Module should have their own DLLs.
One project should be for the external container of the application (like the framework) and this project should bring all other modules (of type web application) in the solution to the external container. (Some thing like we have Frames in HTML). So we will publish the external container web application only at the end of the day and all other web application projects will be accessed via that.
I would like to have separate DLL for each module so I don't need to fear about the application breaking when I am deploying my single DLL which controls the entire suite.
I am not sure whether my thoughts are in the right direction. The end result I am looking for is a well-maintained, organized, and modular web application suite.
It is ASP.NET web forms, not MVC. I will use VS2010 for development.
What are the best approaches to do this?
Edit:
The term external container means it acts like a master page which has links to various modules and the various modules are not always in the same project. They can be separate project under the same solution. And I am under the impression that, by the end of the day, I will publish that project only and it will bring the various modules to it.
I actually think the best approach would be one that does not over-architect. I'm concerned that it seems you are producing an overall architecture without sufficient reason.
Are these all new modules? Then just start writing the first one. Use best practices that apply to single modules.
Then write the second one. You'll find you want to use things you already wrote in the first module. Great. That's what refactoring is for. Refactor these things out into one or more "library" projects, re-run all your unit tests, then proceed with the second module.
Repeat until all modules are done.
At the end of this process, if you needed the kind of architecture you've outlined, then you'll have it. If you needed less, then you'll have less, and you will not have spent time creating an architecture which is not tied to real-world requirements.
I'm not going to say this is a "best approach" but I would recommend looking over Dot Net Nuke (DNN) to get some ideas. This started as the old "I Buy Spy" starter web project that Microsoft distributed to show ASP.NET projects, and it took off from there.
edit:
1.The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
You can do this with DNN. They're also called "modules" in DNN and Drupal.
2.Each Module should have their own DLL's.
Yes, this is a good idea. And you'll see this sort of thing in several content management systems like DNN and Drupal. This way not all implementations of the same website need to have all modules installed.
We have a significant website that is used to host a "service as a solution" application that we charge for (if you aren't an actuary or accountant you won't have heard of it). The lead developer for the past couple years used an earlier version of DotNetNuke as a model for how to refactor the parts of the application that he was allowed to change.
Like others have suggested DNN would probably work for what you're trying to do. If you want to completely roll your own naturally I would turn to some sort of combination of a container "Framework" and a bunch of user controls (.ascx). The container could be as simple as a master page with a menu. Depending on how flexible you want your design you can prefabricate many different pages, each hosting a different control (separate dll as you wish). If you want it to be a little more dynamic you can have one content page that will dynamically load at runtime the desired user control into it. Again this is just a general approach, probably a 30000 feet view into how DNN is implemented anyway.
Name the main project after your company/product and keep it short and simple. You will probably need one or two library projects to support it - these will contain everyday, common logic for such things as error reporting, Web utility methods, etc.
Next, pick one of your intended sub-projects (I don't like the term module in this particular context) and add that to your solution. Whether you are reusing an existing project, or preferably starting from scratch, you will eventually have any common logic in this project moved out to your libraries.
Rinse and repeat. Perhaps take a look at something similar like the Sueetie project which includes several sub-projects like CMS, Blog, Calendar, Forum, etc.
The following article is marked as "outdated" on MSDN but I still think you should take a look at it:
Structuring Solutions and Projects
Also, something similar from the Patterns and Practices Group:
Structuring Projects and Solutions in Team Foundation Source Control