I have to build many data-driven web application for various clients. The aim is to build quickly CRUD screens with ACL (based upon tables and fields).
I'm looking for the pros and cons of every solutions (Filemaker or a web framework like Grails).
Thks
i think it's easier to set up a web framework like the RubyOn Rails i use every day .
But it depends on your skills....
Related
I am having one client who wanted to have a website along with an app on iPhone and Android too. So, I am worried about how to structure my MVC solution architecture to best suit the requirement and re-use the business logic among all the platform using Web API.
Can any one suggest the architecture in bit detail to prefer in the above mentioned requirement.
I've found out n-Tier web application concept like following categories:
1- Database (including database business and table or store procedures and all database stuff)
2- Web. Data (including entities and repositories)
3- Web. Model (including not entities some simple model can transfer to client)
4- Web. Business (in some application is admitted it is not mandatory but it includes some functionality such as how to calculates things)
5- Web. Service (including web API on SOAP restful application)
6- Web. Security (it includes some custom security as you wish but it is not mandatory)
7- Web. Client (including client-side functionalities like jquery, mvvm and some other like authentication, securities implemented in UI)
8- Web. Extension (including extra helper methods and wrapper objects)
9- Web. Handler (including all handler and modules)
These layers could be placed on different projects they could be implemented by MVC or even by asp.net of course with the same concept.
I was wondering if my understanding was right or not? or got any better idea? Could you expand them more or are they limited and enough?
Please guide me what are standards about them?
Did you look MyPrettyCMS Framework in codeplex ?
It's exactely that...
https://myprettycms.codeplex.com
In the next release, it includes Web API and Web API OData Handling.
If you want to follow the developer group, find the Linked in group : myPrettyCMS Happy Contributors Associates
N-tier concept is wider than just listing the exact tiers. This concept helps to divite your application to manageble and isolated levels, which you could change, re-design, substitute without breaking and re-writing the entire application. The number of tiers could vary depending on technology stack you use.
read more here: http://en.wikipedia.org/wiki/Multitier_architecture
You should try looking into the XWA architecture if your primary concern is web applications.
http://madeyski.e-informatyka.pl/download/23.pdf
XWA architecture builds atop the concepts know from the MVC and PCMEF.
I am wondering what is the better way to go. I created a webapi project and am currently working on making my api.
In the future I want a full asp.net mvc 4 website and that could also contain forms to insert data into my database.
I am not sure if I should
a)
Make a new area in my web api project and build my website from there.
b)
Keep it in the same area and just make some new controllers and such in the web api project.
c) add a new asp.net mvc 4 project to my web api solution project.
Definitely two projects. In fact, I'd actually recommend three projects:
MVC website
Class library, for sharing your DAL/Service layers
Web API
Your MVC site shouldn't need to query your Web API, that's just going to create HTTP latency that's unnecessary. Both your MVC site and your Web API, are just "frontends" for your class library. They will both reference the class library and interact with the class library.
A Web API is only necessary if you're trying to provide third-party access or you're interfacing with a project in another language. If everything is .NET then just share the DLLs and call it a day.
K. Scott Allen recently wrote a brilliant post on the Coexistence of ASP.NET MVC and WebAPI it covers the most common scenarios and when it's appropriate to use WebAPI with MVC or when you should just use MVC.
I would use that as your guide pick the solution that best meets your current needs. My advice is to keep it simple and if your requirements are simple then there is no reason not keep WebAPI and MVC in the same project - it works just fine. As your requirements change you can always split them up into different projects or solutions, but by then you will know exactly why you are doing so.
http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx
absolutely,
go through link http://efmvc.codeplex.com/
which is the best architecture to develop the big apps
may this one is help you...
another BEST one MVC N-Tier architecture
MVC ---------> WEB API (services)------ > here BL | DL(ORM) | DB)
which you create this in same solution and build the app...
Separate projects for the web api and the web interface will help split things up, but it does cause duplications. We went that way recently and it works well, but it caused a few problems.
Arguments for having a single project :
Since we don't have a domain name yet, we have our API on the 8080 port. We could use a directory binding to make the API accessible from a sub-directory of the web interface but we were worried about production only bugs about absolute path resolution.
Many settings are shared between the two projects so we have to copy them in both web.config files.
Arguments for having multiple projects :
They are easier to upgrade since they can have different dependencies and they can be built totally independently. For example, our API project uses a few more recent versions of some dependencies.
It forces you to extract all of your business logic into a separate library and makes it easier to think about both projects as separate sub-systems.
It is easier to setup the web interface to a separate machine if the load is too much. This is a concern for us, but that may not be your case.
If I had to make this decision again, I probably wouldn't bother with separate projects unless the system was extremely complex and I needed the additional structure. An argument can be made for both options, but I think the deployment headache it brings is not worth it.
I want to build a RoR web application in SaaS architecture. Should I have a single database for every clients or multiple databases for each client. And also I wonder that each client should use the own separated application on sub domain or not. Although it depends on business logic but I want to learn how I can choose the correct way and what the best practice is.
Thanks,
There is no correct answer here. The first solution would be to have each client completely independent: their own application space and database.
However, you may want to design a framework which is common to all clients, and just change the branding for each client. The downside of this is the effort you need to keep them separated - for instance cross-contamination and security.
I am going to develop a web application, the client left me with the choice of application development, I am currently doing those kind of jobs with vs2008 (.net 3.5), now I wish to develop this new app either in asp.net MVC or develop it using dynamic data entities.
I would like to use this as an opportunity to learn, any guidance will be helpful.
Regarding the application, it is not a very big application but going to be used in multi merchandising stations.
I would set on MVC3.
Disadvantages in my opinion about Dynamic Data Entities:
There is not so much rumor about it in forums like SO or other... might be a indicator that nobody uses it
I had a look at it some times ago, and I didn't like the way it can be extend and modified
I think DD is good for small applications with no big logic (Implementing, Business Layer, Logging, Security etc might be tricky)