Mixing
Writing DAO's for SQL Alchemy backends
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I am working on a SQL Alchemy backed REST service, using Falcon as the framework, and trying to separate out my service layer from my database layer as cleanly as possible, expecting this to scale at some point in the future to many thousands of users and requests.
My background is primarily Java, so I've seen this done many times using the DAO pattern -- a data access object that wraps calls to the database (i.e; create, query, update, delete) and hides the implementation details, like SQL statements, transactions, sessions, commits, etc.. in an object oriented fashion. I'm trying to find out if anyone does this in Python, and would you use the same object-oriented, dependency-injection approach that you would in Java, or would you use a different approach.
Option A:
My experience is to create the DAO's on application startup and "inject" them into the REST service layer where they are needed. So within a Falcon "resource":
class FooResource():
def on_post(self, req, resp):
foo_form = json.loads(req.stream.read().decode("utf-8"))
dao: FooDAO = self.daos[FooDAO.__name__]
dao.create_foo(foo_form)
Here, the self.daos are populated at application startup similar to how you would bootstrap a spring container. The DAO would be instantiated with a SQL Alchemy session registry object, and the session would be created on the fly within the DAO method. The FooDAO would look something like this:
class FooDAO():
def __init__(self, session_registry: scoped_session):
self.session_registry = session_registry
def create_foo(self, foo_form):
session = self.session_registry()
foo = FooModel(foo_form)
session.add(foo)
Option B:
The dependency injection approach is a hard sell to a Python team that is not familiar with these concepts. Another option is to use a static call to the DAO layer:
def on_post(self, req, resp):
foo_form = json.loads(req.stream.read().decode("utf-8"))
session = req.context["session"] # this is created in a Falcon middleware
FooDAO.create_foo(foo_form, session)
In this case the FooDAO would not maintain any state:
class FooDAO():
@staticmethod
def create_foo(self, foo_form, session):
foo = FooModel(foo_form)
session.add(foo)
My experience with statics has been that they are strongly discouraged and create tight coupling between classes. However, I don't see this issue surfacing in the Python community -- perhaps because classes aren't as widely used?
Option C:
The third option would be to simplify and do this without classes. I am not opposed to this idea, however in this approach we would lose some of the benefits of object inheritance and encapsulation.
python oop sqlalchemy
asked Jan 3 at 15:53
user2270347user2270347
11
add a comment |
I am working on a SQL Alchemy backed REST service, using Falcon as the framework, and trying to separate out my service layer from my database layer as cleanly as possible, expecting this to scale at some point in the future to many thousands of users and requests.
My background is primarily Java, so I've seen this done many times using the DAO pattern -- a data access object that wraps calls to the database (i.e; create, query, update, delete) and hides the implementation details, like SQL statements, transactions, sessions, commits, etc.. in an object oriented fashion. I'm trying to find out if anyone does this in Python, and would you use the same object-oriented, dependency-injection approach that you would in Java, or would you use a different approach.
Option A:
My experience is to create the DAO's on application startup and "inject" them into the REST service layer where they are needed. So within a Falcon "resource":
class FooResource():
def on_post(self, req, resp):
foo_form = json.loads(req.stream.read().decode("utf-8"))
dao: FooDAO = self.daos[FooDAO.__name__]
dao.create_foo(foo_form)
Here, the self.daos are populated at application startup similar to how you would bootstrap a spring container. The DAO would be instantiated with a SQL Alchemy session registry object, and the session would be created on the fly within the DAO method. The FooDAO would look something like this:
class FooDAO():
def __init__(self, session_registry: scoped_session):
self.session_registry = session_registry
def create_foo(self, foo_form):
session = self.session_registry()
foo = FooModel(foo_form)
session.add(foo)
Option B:
The dependency injection approach is a hard sell to a Python team that is not familiar with these concepts. Another option is to use a static call to the DAO layer:
def on_post(self, req, resp):
foo_form = json.loads(req.stream.read().decode("utf-8"))
session = req.context["session"] # this is created in a Falcon middleware
FooDAO.create_foo(foo_form, session)
In this case the FooDAO would not maintain any state:
class FooDAO():
@staticmethod
def create_foo(self, foo_form, session):
foo = FooModel(foo_form)
session.add(foo)
My experience with statics has been that they are strongly discouraged and create tight coupling between classes. However, I don't see this issue surfacing in the Python community -- perhaps because classes aren't as widely used?
Option C:
The third option would be to simplify and do this without classes. I am not opposed to this idea, however in this approach we would lose some of the benefits of object inheritance and encapsulation.
python oop sqlalchemy
asked Jan 3 at 15:53
user2270347user2270347
11
add a comment |
I am working on a SQL Alchemy backed REST service, using Falcon as the framework, and trying to separate out my service layer from my database layer as cleanly as possible, expecting this to scale at some point in the future to many thousands of users and requests.
My background is primarily Java, so I've seen this done many times using the DAO pattern -- a data access object that wraps calls to the database (i.e; create, query, update, delete) and hides the implementation details, like SQL statements, transactions, sessions, commits, etc.. in an object oriented fashion. I'm trying to find out if anyone does this in Python, and would you use the same object-oriented, dependency-injection approach that you would in Java, or would you use a different approach.
Option A:
My experience is to create the DAO's on application startup and "inject" them into the REST service layer where they are needed. So within a Falcon "resource":
class FooResource():
def on_post(self, req, resp):
foo_form = json.loads(req.stream.read().decode("utf-8"))
dao: FooDAO = self.daos[FooDAO.__name__]
dao.create_foo(foo_form)
Here, the self.daos are populated at application startup similar to how you would bootstrap a spring container. The DAO would be instantiated with a SQL Alchemy session registry object, and the session would be created on the fly within the DAO method. The FooDAO would look something like this:
class FooDAO():
def __init__(self, session_registry: scoped_session):
self.session_registry = session_registry
def create_foo(self, foo_form):
session = self.session_registry()
foo = FooModel(foo_form)
session.add(foo)
Option B:
The dependency injection approach is a hard sell to a Python team that is not familiar with these concepts. Another option is to use a static call to the DAO layer:
def on_post(self, req, resp):
foo_form = json.loads(req.stream.read().decode("utf-8"))
session = req.context["session"] # this is created in a Falcon middleware
FooDAO.create_foo(foo_form, session)
In this case the FooDAO would not maintain any state:
class FooDAO():
@staticmethod
def create_foo(self, foo_form, session):
foo = FooModel(foo_form)
session.add(foo)
My experience with statics has been that they are strongly discouraged and create tight coupling between classes. However, I don't see this issue surfacing in the Python community -- perhaps because classes aren't as widely used?
Option C:
The third option would be to simplify and do this without classes. I am not opposed to this idea, however in this approach we would lose some of the benefits of object inheritance and encapsulation.
python oop sqlalchemy
asked Jan 3 at 15:53
user2270347user2270347
11
I am working on a SQL Alchemy backed REST service, using Falcon as the framework, and trying to separate out my service layer from my database layer as cleanly as possible, expecting this to scale at some point in the future to many thousands of users and requests.
My background is primarily Java, so I've seen this done many times using the DAO pattern -- a data access object that wraps calls to the database (i.e; create, query, update, delete) and hides the implementation details, like SQL statements, transactions, sessions, commits, etc.. in an object oriented fashion. I'm trying to find out if anyone does this in Python, and would you use the same object-oriented, dependency-injection approach that you would in Java, or would you use a different approach.
Option A:
My experience is to create the DAO's on application startup and "inject" them into the REST service layer where they are needed. So within a Falcon "resource":
class FooResource():
def on_post(self, req, resp):
foo_form = json.loads(req.stream.read().decode("utf-8"))
dao: FooDAO = self.daos[FooDAO.__name__]
dao.create_foo(foo_form)
Here, the self.daos are populated at application startup similar to how you would bootstrap a spring container. The DAO would be instantiated with a SQL Alchemy session registry object, and the session would be created on the fly within the DAO method. The FooDAO would look something like this:
class FooDAO():
def __init__(self, session_registry: scoped_session):
self.session_registry = session_registry
def create_foo(self, foo_form):
session = self.session_registry()
foo = FooModel(foo_form)
session.add(foo)
Option B:
The dependency injection approach is a hard sell to a Python team that is not familiar with these concepts. Another option is to use a static call to the DAO layer:
def on_post(self, req, resp):
foo_form = json.loads(req.stream.read().decode("utf-8"))
session = req.context["session"] # this is created in a Falcon middleware
FooDAO.create_foo(foo_form, session)
In this case the FooDAO would not maintain any state:
class FooDAO():
@staticmethod
def create_foo(self, foo_form, session):
foo = FooModel(foo_form)
session.add(foo)
My experience with statics has been that they are strongly discouraged and create tight coupling between classes. However, I don't see this issue surfacing in the Python community -- perhaps because classes aren't as widely used?
Option C:
The third option would be to simplify and do this without classes. I am not opposed to this idea, however in this approach we would lose some of the benefits of object inheritance and encapsulation.
python oop sqlalchemy
python oop sqlalchemy
asked Jan 3 at 15:53
user2270347user2270347
11
asked Jan 3 at 15:53
user2270347user2270347
11
asked Jan 3 at 15:53
user2270347user2270347
11
asked Jan 3 at 15:53
user2270347user2270347
11
asked Jan 3 at 15:53
user2270347user2270347
11
11
add a comment |
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54025659%2fwriting-daos-for-sql-alchemy-backends%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54025659%2fwriting-daos-for-sql-alchemy-backends%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
