I am still very new to Actionscript and have an okay working knowledge of Flex. I am working on an AIR application that runs a SQLite database underneath. The database is only 3 tables (projects, items and types). I was wondering if Actionscript best practices are to use a data access object or layer to store all of my database functions or to just run them inline as needed. I would assume an access layer would be best for interacting with the database for usability, but I can't seem to find much documentation for SQLite in AIR.
It depends a bit on the complexity of your application, but in general I would propose using an abstraction over the database access. The key is to create an interface that your application will talk to and then provide a SQLite implementation. The benefit is that you can easily create a stub or mock implementation for testing and you can create new implementation that talk to other technologies. The Spring ActionScript framework has some good utilities to achieve this.
I responded to a similar question here.
Related
If have a web app and built in nodejs (sails) and I want to create the same app for mobile using phonegap and local storage (sqlite), is there a way to implement the CRUD actions in the mobile app without programming the DB creation, queries, etc?
If I understood you correctly, you are looking for abstraction layer so that you wouldn't need to handle the database connection by yourself? If so, I haven't actually came across with any such framework, nor was I able to find one with quite extensive googling. It may be because it is still quite rare to use the SQLite, especially on normal web browsers. Also, it is quite trivial to write those operation by yourself and thus you should be able to do it quite easily.
Team A has an enterprise app that uses ADO.NET for data access that executes stored procedures. The data access is encapsulated in it's own project (let's call it DAL.dll)
Team B is creating another unrelated app that's reusing the stored procedures in the enterprise app. This app is currently using the MS application block for data access. The issue we run into is that whenever Team A make any change to the input/output params in the stored procedures, there is a runtime error in Team B's app and this app needs to be updated to accommodate the additional params (or params that were removed). So, most of these go unnoticed until a user complains. At the very least, we would like to have the app throw a compilation error so that the build process warns us of the changes made.
One way to do this is to have Team B's project add a reference to the DAL.dll
I'd like to know if there are any other cleaner ways of solving the issue. We are ready to replace Team B's MS Data application block to use a different technology (Entity Framework?) if necessary.
Among the other answers, I'd strongly suggest getting those stored procedures into source control, in a Database Project. You then may be able to use the features of your source control system to do several things:
Lock some of the code so that it cannot be changed
Give you notifications if the code is changed
Warn you if the stored procedures change in a way that would prevent them from being called
Branch the stored procedures so that each team can have their own version of changed code, while keeping the unchanged stored procedures common. You of course will need to separate the different versions in the database.
I agree with the other posters on this thread that you should not share stored procedure's across different .NET DLL's, that is just a recipe for disaster. I would also shy away from ORM's like Entity Framework if you are doing anything at all complicated with your database schema because ORM's excel at getting a simple object model translated from your .NET application classes into SQL tables and SP's, but traditionally do poorly at optimizing them for performance on the database side. There will be people who claim otherwise, and they may have a valid point if you are an expert in wrangling an ORM to do waht you want like they are, but chances are you are not and it will cause you headaches in the long run.
A shared data access layer might work, but conceptually you are then just changing the implementation of the dependency from some code that a DBA wrote to some code that a .NET programmer wrote. Yes, you can use integration tests to achieve better verifiability, but the same case could be made for SQL with tools like Red Gate's SQL Test. I would shy away from this approach if the two applications are already experiencing some sort of pain from sharing SP's. That is an indication that the dependency just should be done away with.
If it were up to me, I'd just make a new schema for Team B's app. You can read more about schemas in SQL Server here: MSDN Schema description for 2008 R2. You can think of them as namespaces for SQL Server but with some additional bells and whistles like permission and access control. Separating out your different applications into separate schemas on the same shared database will probably make for the most flexible implementation in the long run.
unrelated app that's reusing the stored procedures in the enterprise app
If these two application are really unrelated why are those sharing procedures or even the same database. I know this is a long read, but I recommend you to read this: A Better Path to Enterprise Architectures
The partioning concept in there relates to the bounded context in Domain driven design:
Multiple models are in play on any large project. Yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. Communication among team members becomes confusing. It is often unclear in what context a model should not be applied.
Therefore: Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.
It is expected you end with problems when you don't explicitely deal with this. You're lucky you're seeing early failures, as it can turn into problems much harder to find on the long run.
Analyze the problem again with the above in mind. Consider if you're missing some explicit context where this common functionality should live.
My question is: which team owns the store procedured and the database shared? Usually as a good architecture/design, you should not have two different apps sharing same database / procedures.
A better way to share data/functionality between two different applications is through a services or API, so the team who owns the functionality would be responsible to maintain it.
Also, have a good communication between both teams is highly recommend.
Depending on the owner of the DAL project, you could host web services and share the API. That way, you separate the Data Access Layer from the business logic, which allows anyone to use the same DAL without having to publish it to each different location.
From my point of view, it looks like both Team A and Team B should share the same core model and look at Multitier architecture as a possible solution.
It sounds like it would make sense to create a shared DAL that both applications can share.
I would add unit tests (or really integration tests) to make sure the DAL is compatible with the apps after changes. That way your tests would fail if incompatible changes have been made
"I'd like to know if there are any other cleaner ways of solving the issue."
The cleanest way is for Team B to sit down with Team A and encapsulate the relevant business logic into a shared API. It doesn't matter so much how you implement that API; what does matter is that the API's interface is documented and versioned so everyone knows what to expect.
One reasonable mechanism for this in a .NET environment is to use Microsoft's WebAPI.
In short, the question of "how do we share a stored procedure?" is most likely looking at the wrong level of abstraction.
What do you think of using modern data access technologies in legacy apps? Not replacing the data access layer with a new layer, but having a mix of data access methods in the same layer.
Say the current Data Access Layer in my legacy app uses DataSet, SQLDataAdapter, SQLCommand and Stored Proc to access data from the database.
Are there any real reasons not to include Linq to SQL (dbml) or Entity Framework classes (edmx) classes in the DAL? Is there any harm in having a mix of Data Access Methods in the DAL, or in the same class?
Generally there is no harm but unless you plan to do slow upgrade by replacing parts of legacy application when doing new development I would not do it. It will make the whole application like one big mess of many technologies, it will have worse maintenance and it can also mess its design / architecture.
The exception can be implementing new component of the application which is isolated from the rest. In such case you can probably design it from scratch and use newer technology but for support / maintenance team it can still be nuisance.
I have ASP.NET project and I want to know what is better to use.
ODBC connection and with Server Explorer (drag and drop make DataSet and modify it) or do some DBconnect class with connection to database, queries and use it for GridView?
When I use server explorer, I don't have good feeling because all logic is on aspx page and I do not separate from the application layer logic layer.
It will be a lagre application, databese(PostreSQL) have 18 tables and difficult constraints and application have to generate some documents etc. .
"Better" depends entirely on your situation. Is the purpose to get something done as quickly as possible for internal users at your company, or is this going to be a commercial site that will need to be highly extensible and needs to be as easy as possible to maintain? Will you need to integrate with other platforms possibly built using other languages at some point? The answers to all of these questions should affect your decision.
If you're looking to separate your project into distinct layers, then I would recommend an ORM such as NHibernate or Entity Framework (there are other commercially available ORM products out there, but these are the ones I'm familiar with and which you can easily get help with on this site).
Create a DataSource with LINQ to Entity. It let you the liberty of LINQ with the peace of mind of when you change something il will break your build so you will be able to debug more efficiently.
Well if you have total flexibility, I would recommend using C# ASP.NET 4 with MVC3 razor for the UI and application code. Use Entity Framework 4.1 code first for the data access layer.
This way you will always work with real objects that you create, and with List<realtype> instead of the total mess that exists with datasets.
I'm not sure what I'm missing here, but I can't find a reliable ORM for AIR.
The ones I find are not documented well and don't seem to have a solid following. Is a solid ORM non-existant at this point?
Ones I'm aware of:
http://flexorm.riaforge.org/
http://code.google.com/p/airorm/
http://code.google.com/p/air-activerecord/
I Never used it but have a look at the Cairngorm Persistance Library :
http://sourceforge.net/adobe/cairngorm/wiki/HowtoUsetheCairngormPersistenceLibrary/
Looks like what you're looking for :
"The Persistence library eases the communication between an Adobe AIR application and an SQLite database. Both use different type systems (relational SQL versus object-oriented ActionScript). This Object Relational Mapping (ORM) library follows an iBATIS approach."
Check out Flextrine at www.flextrine.com
This is a client/server Flex ORM solution that integrates with Doctrine 2.
ORM frameworks are designed to help access a database. Since Flex has no direct access to a database, an ORM framework would be extremely limited.
I assume the projects you link to are for dealing with AIR and the embedded SQLLite database.
There are plugins for Flash Builder that will generate value objects based on the database you specify. Originally they were just for ColdFusion, but I think they've expanded to include other technologies. However, I would not consider these "code generators" the same as an ORM.
Check out FxORM. It has nice documentation with examples if you follow the link.